From jim at cos.ru  Mon Nov  2 10:48:41 2015
From: jim at cos.ru (Jim Klimov)
Date: Mon, 02 Nov 2015 11:48:41 +0100
Subject: [OmniOS-discuss] Bloody Terminfo problems
Message-ID: <fc775c342508.56374d99@cos.ru>


 Hello all,




 TL;DR: The OmniOS terminfo package seems broken after Oct 22 and delivers too few files. Packaged software does not fall back to other available locations.




 Details:




 A week or two ago, different CLI programs began acting up on my OmniOS box, saying nonsense like this:




 # mc
 Error opening terminal: xterm.




 Same for vt100, vt220, ansi...

 I have terminfo packages installed and up-to-date, and while looking at the system I see 3 locations at least:

 # find /opt -name terminfo -ls
   1124    2 drwxr-xr-x  14 root     root           14 Oct 29 14:45 /opt/local/share/lib/terminfo





 # find /usr -name terminfo -ls
    349    4 drwxr-xr-x  44 root     bin            44 Dec  4  2014 /usr/gnu/share/terminfo
    332    0 lrwxrwxrwx   1 root     root           17 Dec  4  2014 /usr/gnu/lib/terminfo -> ../share/terminfo
  29464    4 drwxr-xr-x  44 root     bin            44 Dec  4  2014 /usr/share/lib/terminfo




 The /usr ones seem similar to OI/Hipster - they contain seemingly equivalent content except most of the files are different at binary level. Apparently, they come from terminfo and ncurses, and maybe should be merged(?) in illumos-gate(?):

 # pkg search xterm
 INDEX      ACTION VALUE                          PACKAGE
 basename   file   usr/gnu/share/terminfo/x/xterm pkg:/library/ncurses at 5.9-0.151015
 basename   file   usr/share/lib/terminfo/x/xterm pkg:/system/data/terminfo at 0.5.11-0.151015





 The /opt location is rather empty in comparison (and `pkg search -r filenames` fails to find what package this should have been, also on older BEs):




 # find /opt | grep terminfo | sort
 /opt/local/share/lib/terminfo
 /opt/local/share/lib/terminfo/d
 /opt/local/share/lib/terminfo/d/dec+pp
 /opt/local/share/lib/terminfo/d/dec+sl
 /opt/local/share/lib/terminfo/g
 /opt/local/share/lib/terminfo/g/gnome-2012
 /opt/local/share/lib/terminfo/i
 /opt/local/share/lib/terminfo/i/iterm
 /opt/local/share/lib/terminfo/l
 /opt/local/share/lib/terminfo/l/linux2.2
 /opt/local/share/lib/terminfo/l/linux2.6
 /opt/local/share/lib/terminfo/l/linux3.0
 /opt/local/share/lib/terminfo/m
 /opt/local/share/lib/terminfo/m/mach-gnu
 /opt/local/share/lib/terminfo/m/mach-gnu-color
 /opt/local/share/lib/terminfo/m/minix-3.0
 /opt/local/share/lib/terminfo/m/mlterm2
 /opt/local/share/lib/terminfo/m/mlterm3
 /opt/local/share/lib/terminfo/n
 /opt/local/share/lib/terminfo/n/netbsd6
 /opt/local/share/lib/terminfo/n/nsterm-256color
 /opt/local/share/lib/terminfo/n/nsterm-build326
 /opt/local/share/lib/terminfo/n/nsterm-build343
 /opt/local/share/lib/terminfo/o
 /opt/local/share/lib/terminfo/o/old-st
 /opt/local/share/lib/terminfo/p
 /opt/local/share/lib/terminfo/p/pccon
 /opt/local/share/lib/terminfo/p/pccon+base
 /opt/local/share/lib/terminfo/p/pccon+colors
 /opt/local/share/lib/terminfo/p/pccon+keys
 /opt/local/share/lib/terminfo/p/pccon+sgr+acs
 /opt/local/share/lib/terminfo/p/pccon+sgr+acs0
 /opt/local/share/lib/terminfo/p/pccon-m
 /opt/local/share/lib/terminfo/p/pccon0
 /opt/local/share/lib/terminfo/p/pccon0-m
 /opt/local/share/lib/terminfo/p/putty+fnkeys
 /opt/local/share/lib/terminfo/p/putty+fnkeys+esc
 /opt/local/share/lib/terminfo/p/putty+fnkeys+linux
 /opt/local/share/lib/terminfo/p/putty+fnkeys+sco
 /opt/local/share/lib/terminfo/p/putty+fnkeys+vt100
 /opt/local/share/lib/terminfo/p/putty+fnkeys+vt400
 /opt/local/share/lib/terminfo/p/putty+fnkeys+xterm
 /opt/local/share/lib/terminfo/p/putty-sco
 /opt/local/share/lib/terminfo/s
 /opt/local/share/lib/terminfo/s/screen+italics
 /opt/local/share/lib/terminfo/s/screen.konsole-256color
 /opt/local/share/lib/terminfo/s/screen.mlterm-256color
 /opt/local/share/lib/terminfo/s/screen.putty
 /opt/local/share/lib/terminfo/s/screen.putty-256color
 /opt/local/share/lib/terminfo/s/screen.vte-256color
 /opt/local/share/lib/terminfo/s/screen.xterm-256color
 /opt/local/share/lib/terminfo/s/simpleterm
 /opt/local/share/lib/terminfo/s/st
 /opt/local/share/lib/terminfo/s/st-16color
 /opt/local/share/lib/terminfo/s/st-256color
 /opt/local/share/lib/terminfo/s/stterm
 /opt/local/share/lib/terminfo/s/stterm-16color
 /opt/local/share/lib/terminfo/s/stterm-256color
 /opt/local/share/lib/terminfo/s/sun+sl
 /opt/local/share/lib/terminfo/t
 /opt/local/share/lib/terminfo/t/teken
 /opt/local/share/lib/terminfo/t/terminator
 /opt/local/share/lib/terminfo/t/terminology
 /opt/local/share/lib/terminfo/t/tmux
 /opt/local/share/lib/terminfo/t/tmux-256color
 /opt/local/share/lib/terminfo/v
 /opt/local/share/lib/terminfo/v/vt520ansi
 /opt/local/share/lib/terminfo/v/vte-2012
 /opt/local/share/lib/terminfo/v/vte-2014
 /opt/local/share/lib/terminfo/x
 /opt/local/share/lib/terminfo/x/xterm+256setaf
 /opt/local/share/lib/terminfo/x/xterm+kbs
 /opt/local/share/lib/terminfo/x/xterm+sm+1002
 /opt/local/share/lib/terminfo/x/xterm+sm+1003
 /opt/local/share/lib/terminfo/x/xterm+sm+1005
 /opt/local/share/lib/terminfo/x/xterm+sm+1006
 /opt/local/share/lib/terminfo/x/xterm+tmux
 /opt/local/share/lib/terminfo/x/xterm+x10mouse
 /opt/local/share/lib/terminfo/x/xterm+x11hilite
 /opt/local/share/lib/terminfo/x/xterm+x11mouse
 /opt/local/share/lib/terminfo/x/xterm-1005
 /opt/local/share/lib/terminfo/x/xterm-1006
 /opt/local/share/lib/terminfo/x/xterm-x10mouse
 /opt/local/share/lib/terminfo/x/xterm-x11hilite
 /opt/local/share/lib/terminfo/x/xterm-x11mouse





 But it is the one searched by software (and no fallbacks to other locations). For example, trussing that "mc" call I see:




 # truss -fl -wall -rall mc 2>&1

 ...

 14731/1:        getuid()                                        = 0 [0]
 14731/1:        ioctl(1, TCGETS, 0x00508360)                    Err#22 EINVAL
 14731/1:        fstat(2, 0xFFFFFD7FFFDFE790)                    = 0
 Cannot get terminal settings: 14731/1:  write(2, 0x004EAD60, 30)                        = 30
 14731/1:           C a n n o t   g e t   t e r m i n a l   s e t t i n g s :
 Invalid argument (22)14731/1:   write(2, 0x00515DC0, 21)                        = 21
 14731/1:           I n v a l i d   a r g u m e n t   ( 2 2 )

 14731/1:        write(2, "\r\n", 2)                             = 2
 14731/1:        sigaction(SIGCLD, 0xFFFFFD7FFFDFFAE0, 0x00000000) = 0
 14731/1:        sigaction(SIGTSTP, 0x00000000, 0x0051AC20)      = 0
 14731/1:        ioctl(1, TCGETA, 0xFFFFFD7FFFDFF9E0)            Err#22 EINVAL
 14731/1:        stat("/root/.terminfo", 0x0054E2D0)             Err#2 ENOENT
 14731/1:        stat("/opt/local/share/lib/terminfo", 0x0054E2D0) = 0
 14731/1:        time()                                          = 1446459993
 14731/1:        access("/opt/local/share/lib/terminfo/x/xterm", R_OK) Err#2 ENOENT
 Error opening terminal: 14731/1:        write(2, 0xFFFFFD7FFD1390DD, 24)                = 24
 14731/1:           E r r o r   o p e n i n g   t e r m i n a l :
 xterm14731/1:   write(2, " x t e r m", 5)                       = 5
 .
 14731/1:        write(2, " .\n", 2)                             = 2
 14731/1:        _exit(1)





 In particular, the larger set of files was there until Oct 22 as I can see in my snapshots, and then thousands of them went AWOL:




 # find postupgrade_pkgips-20151022T174922Z/share/lib/terminfo/ -type f | wc -l
 2616


 # find /opt/local/share/lib/terminfo/ -type f | wc -l
 72





 Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/d0dde493/attachment.html>

From jim at cos.ru  Mon Nov  2 11:19:55 2015
From: jim at cos.ru (Jim Klimov)
Date: Mon, 02 Nov 2015 12:19:55 +0100
Subject: [OmniOS-discuss] OmniOS backup box hanging regularly
In-Reply-To: <20151027095642.GA13407@gutsman.lotheac.fi>
References: <fc3ca2101e41.56294013@cos.ru> <fc3bc0e92848.562a26c0@cos.ru>
	<02DF3A33-F955-4F86-A478-0D639CB500F1@cos.ru>
	<20151023171047.GA25370@gutsman.lotheac.fi>
	<54A6F787-8791-4C94-85AB-BB3615077387@cos.ru>
	<20151027095642.GA13407@gutsman.lotheac.fi>
Message-ID: <fc775c362dc8.563754eb@cos.ru>


 Small follow-up:

 For now I just disabled the "frequent" and "hourly" schedules, and the box worked for about a week without freezing over. Good tendency ;)

 Looking at this, I guess there is similar mis-behavior on one of the Sol10 boxes where the original (pre-TimeSlider) zfs-autosnap KSH scripts were ported. It also goes down once in a few weeks with forking problems, although we thought it may be due to backup jobs (exporting data from the box) being too heavy at times. Maybe too many snapshot jobs collide instead...

 Perhaps we should look at porting Python timeslider here and there instead, or really learn znapzend...




 Thanks,
 Jim



----- ???????? ????????? -----
??: Lauri Tirkkonen <lotheac at iki.fi>
????: Tuesday, October 27, 2015 13:40
????: Re: [OmniOS-discuss] OmniOS backup box hanging regularly
???? (To): Jim Klimov <jim at cos.ru>
????? (Cc): omnios-discuss at lists.omniti.com

 > On Tue, Oct 27 2015 09:49:40 +0100, Jim Klimov wrote:
 > > So far I use a mix of 'standard' time-slider and additionally 
 > my script that kills oldest snapshot groups (chosen by pattern 
 > of automatic snaps) to keep a specified watermark of free space.
 > 
 > Yeah, we were previously using zfs-auto-snap from OpenSolaris 
 > before it
 > became time-slider (with one or two local patches). 
 > 
 > > Something in this simple activity is enough to bring the box 
 > down into swapping until the deadman knocks to interrupt the 
 > infinite loop looking for a free page, and I've got a screenshot 
 > to prove this theory ;)
 > 
 > In your previous mail you have a 'top' listing with way too many 'zfs'
 > processes owned by zfssnap, and all are hundreds of megabytes in RSS.
 > That sounds like a problem. IIRC, one problematic configuration that
 > caused issues like this was a single filesystem setting a
 > zfs-auto-snapshot property locally in a large tree where it also
 > inherited it from the parent. My memory on this is a bit hazy though.
 > 
 > > I wonder why doesn't the offending process die on some failed 
 > malloc...
 > Good question.
 > 
 > -- 
 > Lauri Tirkkonen | lotheac @ IRCnet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/9de71ccc/attachment-0001.html>

From lotheac at iki.fi  Mon Nov  2 11:22:02 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Mon, 2 Nov 2015 13:22:02 +0200
Subject: [OmniOS-discuss] Bloody Terminfo problems
In-Reply-To: <fc775c342508.56374d99@cos.ru>
References: <fc775c342508.56374d99@cos.ru>
Message-ID: <20151102112202.GA25290@gutsman.lotheac.fi>

On Mon, Nov 02 2015 11:48:41 +0100, Jim Klimov wrote:
>  TL;DR: The OmniOS terminfo package seems broken after Oct 22 and
>  delivers too few files. Packaged software does not fall back to other
>  available locations.

Packaged by who?

>  Same for vt100, vt220, ansi...
> 
>  I have terminfo packages installed and up-to-date, and while looking at the system I see 3 locations at least:
> 
>  # find /opt -name terminfo -ls
>    1124    2 drwxr-xr-x  14 root     root           14 Oct 29 14:45 /opt/local/share/lib/terminfo

Not shipped by OmniOS. Maybe this is from pkgsrc?

>  The /usr ones seem similar to OI/Hipster - they contain seemingly
>  equivalent content except most of the files are different at binary
>  level. Apparently, they come from terminfo and ncurses, and maybe
>  should be merged(?) in illumos-gate(?):
> 
>  # pkg search xterm
>  INDEX      ACTION VALUE                          PACKAGE
>  basename   file   usr/gnu/share/terminfo/x/xterm pkg:/library/ncurses at 5.9-0.151015
>  basename   file   usr/share/lib/terminfo/x/xterm pkg:/system/data/terminfo at 0.5.11-0.151015

Well, -gate ships its own curses, and it's not exactly compatible with
ncurses from what I understand.

>  But it is the one searched by software (and no fallbacks to other
>  locations). For example, trussing that "mc" call I see:

mc is also not shipped by OmniOS AFAIK. 'vim' for me is searching
/usr/gnu/share/terminfo correctly, not even stat()ing anything under
/opt. Maybe you need to look at whoever shipped your mc?

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From jim at cos.ru  Mon Nov  2 11:30:57 2015
From: jim at cos.ru (Jim Klimov)
Date: Mon, 02 Nov 2015 12:30:57 +0100
Subject: [OmniOS-discuss] Bloody Terminfo problems
In-Reply-To: <20151102112202.GA25290@gutsman.lotheac.fi>
References: <fc775c342508.56374d99@cos.ru>
	<20151102112202.GA25290@gutsman.lotheac.fi>
Message-ID: <fc7733bc173e.56375781@cos.ru>


 Right, good shot Lauri. 

 Sorry for confusing /opt/omni with /opt/local. Something mis-clicked in my mind.

 So it is a pkgsrc problem then (and/or a problem during its upgrade, done essentially by unpacking the new bootstrap over an old location and running `pkgin -y update && pkgin -y full-upgrade`).

 Jim

----- ???????? ????????? -----
??: Lauri Tirkkonen <lotheac at iki.fi>
????: Monday, November 2, 2015 12:23
????: Re: [OmniOS-discuss] Bloody Terminfo problems
???? (To): omnios-discuss at lists.omniti.com

 > On Mon, Nov 02 2015 11:48:41 +0100, Jim Klimov wrote:
 > >  TL;DR: The OmniOS terminfo package seems broken after 
 > Oct 22 and
 > >  delivers too few files. Packaged software does not fall 
 > back to other
 > >  available locations.
 > 
 > Packaged by who?
 > 
 > >  Same for vt100, vt220, ansi...
 > > 
 > >  I have terminfo packages installed and up-to-date, and 
 > while looking at the system I see 3 locations at least:
 > > 
 > >  # find /opt -name terminfo -ls
 > >    1124    2 drwxr-xr-x  14 
 > root     root           14 Oct 29 14:45 /opt/local/share/lib/terminfo
 > 
 > Not shipped by OmniOS. Maybe this is from pkgsrc?
 > 
 > >  The /usr ones seem similar to OI/Hipster - they contain 
 > seemingly>  equivalent content except most of the files are 
 > different at binary
 > >  level. Apparently, they come from terminfo and ncurses, 
 > and maybe
 > >  should be merged(?) in illumos-gate(?):
 > > 
 > >  # pkg search xterm
 > >  INDEX      ACTION 
 > VALUE                          PACKAGE
 > >  basename   file   
 > usr/gnu/share/terminfo/x/xterm pkg:/library/ncurses at 5.9-0.151015
 > >  basename   file   
 > usr/share/lib/terminfo/x/xterm pkg:/system/data/terminfo at 0.5.11-
 > 0.151015
 > Well, -gate ships its own curses, and it's not exactly 
 > compatible with
 > ncurses from what I understand.
 > 
 > >  But it is the one searched by software (and no fallbacks 
 > to other
 > >  locations). For example, trussing that "mc" call I see:
 > 
 > mc is also not shipped by OmniOS AFAIK. 'vim' for me is searching
 > /usr/gnu/share/terminfo correctly, not even stat()ing anything under
 > /opt. Maybe you need to look at whoever shipped your mc?
 > 
 > -- 
 > 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/20151102/3afbb7c0/attachment.html>

From jperkin at joyent.com  Mon Nov  2 11:36:59 2015
From: jperkin at joyent.com (Jonathan Perkin)
Date: Mon, 2 Nov 2015 11:36:59 +0000
Subject: [OmniOS-discuss] Bloody Terminfo problems
In-Reply-To: <fc7733bc173e.56375781@cos.ru>
References: <fc775c342508.56374d99@cos.ru>
	<20151102112202.GA25290@gutsman.lotheac.fi>
	<fc7733bc173e.56375781@cos.ru>
Message-ID: <20151102113659.GC22681@joyent.com>

* On 2015-11-02 at 11:30 GMT, Jim Klimov wrote:

>  Right, good shot Lauri. 
> 
>  Sorry for confusing /opt/omni with /opt/local. Something mis-clicked in my mind.
> 
>  So it is a pkgsrc problem then (and/or a problem during its upgrade, done essentially by unpacking the new bootstrap over an old location and running `pkgin -y update && pkgin -y full-upgrade`).

There is insufficient information in the quoted mail to figure out
what the problem is here, and I've only been copied in half way
through the thread.  Please can you raise a bug via:

  https://github.com/joyent/pkgsrc/issues

with details and how to reproduce?

Thanks,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

From philip.robar at gmail.com  Mon Nov  2 19:06:04 2015
From: philip.robar at gmail.com (Philip Robar)
Date: Mon, 2 Nov 2015 14:06:04 -0500
Subject: [OmniOS-discuss] OmniOS in Vagrant Catalog broken
Message-ID: <CAOi9mGLwnjGb+d30M-Q4JsTZNVGXJWpx+ss7Dy8BS=S9raYN0w@mail.gmail.com>

The top listed OmniOS Vagrant box, omniti/omnios-r151014, is broken in
several ways. There's no indication of who created it so I assume that it
didn't come from OmniTi, but I'm posting this so that others can avoid the
frustration of trying to get it to work. (Problems include, no guest
additions and public bridged networking not configuring correctly.)

I didn't try the version mirrored from OmniTI by Phil Ross as I eventually
figured out how to get the direct download version to work. (Vagrant's
built-in help could be a little clearer on how "--name" works.) Thanks to
OmniTI for providing this.

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/aa0ee980/attachment.html>

From philip.robar at gmail.com  Mon Nov  2 19:28:07 2015
From: philip.robar at gmail.com (Philip Robar)
Date: Mon, 2 Nov 2015 14:28:07 -0500
Subject: [OmniOS-discuss] New metapackage --> illumos-tools
In-Reply-To: <7D40F53B-0F1C-4147-9E64-0C29E649EDCF@omniti.com>
References: <7D40F53B-0F1C-4147-9E64-0C29E649EDCF@omniti.com>
Message-ID: <CAOi9mGLgqL==Ns3FBjs3Jho+RX=n9fH-DxmX-KpA9ZMLt88=Dg@mail.gmail.com>

On Wed, Oct 14, 2015 at 7:45 PM, Dan McDonald <danmcd at omniti.com> wrote:

> IF you want to build illumos-omnos or illumos-gate on an OmniOS r151014 or
> later installation, you can do so now simply by uttering:
>
>         pkg install developer/illumos-tools
> ...
>


Sorry I didn't have something like this sooner.  I've also updated the How
> to Build illumos page on the illumos wiki.
>
> Happy installing!
> Dan
>

I set up a Vagrant box using the box provided by OmniTi and followed the
directions at the wiki and ran into the problem of the compiler and dmake
not being found. I've attached the log files and here are my diffs to
illumos.sh. The OmniOS Mods and build without Sun Studio are cut and pasted
from the wiki.

vagrant at omnios-vagrant:/export/home/vagrant/code/illumos-gate$ echo $PATH
/usr/bin:/usr/sbin:/sbin:/usr/gnu/bin:/opt/omni/bin:/opt/gcc-4.4.4/bin:/opt/sunstudio12.1/bin

vagrant at omnios-vagrant:/export/home/vagrant/code/illumos-gate$ diff
illumos.sh*
110c110,111
< export MAILTO="$STAFFER"
---
> #export MAILTO="$STAFFER"
> export MAILTO="philip.robar at gmail.com"
215c216
< export ENABLE_IPP_PRINTING=
---
> #export ENABLE_IPP_PRINTING=
219c220
< export ENABLE_SMB_PRINTING=
---
> #export ENABLE_SMB_PRINTING=
226a228,249
>
> # OmniOS Mods
>
> # Help OmniOS find lint
> export SPRO_ROOT='/opt'
>
> # OmniOS places GCC 4.4.4 differently.
> export GCC_ROOT=/opt/gcc-4.4.4/
>
> # These are required for building on OmniOS.
> export PERL_VERSION=5.16.1
> export PERL_PKGVERS=
> export PERL_ARCH=i86pc-solaris-thread-multi-64int
>
> # SET ONNV_BUILDNUM appropriately - to ONU r151014, set this to 151014.
> export ONNV_BUILDNUM=151014
>
> # The following are added to build without Sun Studio
> export CW_NO_SHADOW=1
> export ONLY_LINT_DEFS=-I${SPRO_ROOT}/sunstudio12.1/prod/include/lint
> export __GNUC=""
> #unset __SUNC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/fce993b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mail_msg
Type: application/octet-stream
Size: 601 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/fce993b6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nightly.log
Type: application/octet-stream
Size: 3032 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151102/fce993b6/attachment-0003.obj>

From bfriesen at simple.dallas.tx.us  Tue Nov  3 14:29:14 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 3 Nov 2015 08:29:14 -0600 (CST)
Subject: [OmniOS-discuss] pkgrecv -s
 http://pkg.omniti.com/omnios/r151014/ -d /tank/repo '*' seems to be broken
In-Reply-To: <AAD28670-63A5-46A7-84D8-A1DE3DA9E08C@omniti.com>
References: <562E912A.80808@btconnect.com>
	<43AF2ECC-D806-47BD-B313-23DAFE7F4563@omniti.com>
	<562FAE66.8080704@btconnect.com>
	<AAD28670-63A5-46A7-84D8-A1DE3DA9E08C@omniti.com>
Message-ID: <alpine.GSO.2.01.1511030826390.1673@freddy.simplesystems.org>

On Tue, 27 Oct 2015, Dan McDonald wrote:

> Try -m latest... it could just be the sheer number of packages 
> you're transferring. We still use the tiny CherryPy webserver at the 
> repo-box end.

It worked for me here (with '-m latest'):

pkgrecv -s http://pkg.omniti.com/omnios/r151014/ -d /tank/repo -m latest '*'
Processing packages for publisher omnios ...
Retrieving and evaluating 1019 package(s)...
PROCESS                                         ITEMS    GET (MB)   SEND (MB)
Completed                                   1019/1019   1011/1011   2946/2946

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From danmcd at omniti.com  Tue Nov  3 15:56:19 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 10:56:19 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
Message-ID: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>

Say hello to OmniOS r151016:

	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151016

The big highlights include:

	- Userland now compiled with gcc5.1.

	- New and complete "illumos-tools" package available for more expedient illumos development

	- netperf and iperf now available for all of your network measuring needs.

	- Up to date with October illumos-gate

	- New installs get OpenSSH by default, and OpenSSH is now easier to switch to or from.  (Thanks to Lauri "lotheac" Tirkkonen for this!)

OmniOS r151016 is the next Stable release.  r151014 now assumes its role as LTS.  (There will be an r151014 update later this week, with one bugfix from illumos-gate that needs to be brought back.)

If you took advantage of linked-image zones in r151014, make sure you read the upgrade instructions.  You can do it more quickly than in the past, but it requires a bit of setup.

Thank you to the OmniOS community for your feedback and support!
Dan McDonald -- OmniOS Engineering


From danmcd at omniti.com  Tue Nov  3 20:20:00 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 15:20:00 -0500
Subject: [OmniOS-discuss] First post-016 security update
Message-ID: <3FC029B6-08C7-464C-A04C-DD9600CCF484@omniti.com>

Mozilla decided to disclose vulnerabilities in NSS and NSPR on 151016 release day.  To that end, you should now "pkg update" any r151014 or r151016 deployment you have.  New packages include:

  library/nspr
    4.10.8-0.151014:20150913T204455Z -> 4.10.10-0.151014:20151103T201026Z
  library/nspr/header-nspr
    4.10.8-0.151014:20150913T204438Z -> 4.10.10-0.151014:20151103T201017Z
  system/library/mozilla-nss
    3.20-0.151014:20150913T204424Z -> 3.20.1-0.151014:20151103T201005Z
  system/library/mozilla-nss/header-nss
    3.20-0.151014:20150913T204334Z -> 3.20.1-0.151014:20151103T200956Z
  web/ca-bundle
    5.11-0.151014:20150914T123241Z -> 5.11-0.151014:20151103T201037Z

And their moral equivalents for r151016 (which are the same versions, just with different 1510xx in their version strings).

Happy updating!
Dan


From contact at jacobvosmaer.nl  Tue Nov  3 20:43:37 2015
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Tue, 3 Nov 2015 21:43:37 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
Message-ID: <CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>

Hi Dan, list,

Something is going wrong for me with openssh, going from 151014 to 151016.
I don't recall doing anything funny with SunSSH in the past. What am I
doing wrong here?

microbox:~ jacob$ sudo pkg update
Creating Plan (Running solver): |
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to latest
available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:

  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z
  pkg://omnios/incorporation/jeos/illumos-gate at 11
,5.11-0.151016:20151102T185724Z
  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11
,5.11-0.151016:20151102T183750Z
  pkg://omnios/incorporation/jeos/omnios-userland at 11
,5.11-0.151016:20151102T185924Z

The following indicates why the system cannot update to the latest version:

  No suitable version of required package
pkg://omnios/network/openssh at 7.1.1,5.11-0.151016:20151102T190704Z
found:
    Reject:  pkg://omnios/network/openssh at 7.1.1
,5.11-0.151016:20151102T190704Z
    Reason:  Package contains 'exclude' dependency pkg:/network/ssh on
installed package
  No suitable version of required package
pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z
found:
    Reject:  pkg://omnios/network/openssh-server at 7.1.1
,5.11-0.151016:20151102T190719Z
    Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh
on installed package
microbox:~ jacob$ pkg publisher
PUBLISHER                   TYPE     STATUS P LOCATION
omnios                      origin   online F
http://pkg.omniti.com/omnios/r151016/
ms.omniti.com               origin   online F
http://pkg.omniti.com/omniti-ms/
microbox:~ jacob$ pkg list | grep ssh
network/ssh                                       0.5.11-0.151014
 i--
network/ssh/ssh-key                               0.5.11-0.151014
 i--
service/network/ssh                               0.5.11-0.151014
 i--



2015-11-03 16:56 GMT+01:00 Dan McDonald <danmcd at omniti.com>:

> Say hello to OmniOS r151016:
>
>         http://omnios.omniti.com/wiki.php/ReleaseNotes/r151016
>
> The big highlights include:
>
>         - Userland now compiled with gcc5.1.
>
>         - New and complete "illumos-tools" package available for more
> expedient illumos development
>
>         - netperf and iperf now available for all of your network
> measuring needs.
>
>         - Up to date with October illumos-gate
>
>         - New installs get OpenSSH by default, and OpenSSH is now easier
> to switch to or from.  (Thanks to Lauri "lotheac" Tirkkonen for this!)
>
> OmniOS r151016 is the next Stable release.  r151014 now assumes its role
> as LTS.  (There will be an r151014 update later this week, with one bugfix
> from illumos-gate that needs to be brought back.)
>
> If you took advantage of linked-image zones in r151014, make sure you read
> the upgrade instructions.  You can do it more quickly than in the past, but
> it requires a bit of setup.
>
> Thank you to the OmniOS community for your feedback and support!
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> 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/20151103/e55975fd/attachment.html>

From gary at genashor.com  Tue Nov  3 20:49:42 2015
From: gary at genashor.com (Gary Gendel)
Date: Tue, 3 Nov 2015 15:49:42 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
Message-ID: <56391DE6.6050807@genashor.com>

Dan,

Thanks.  Just for information, I updated and it broke pkgsrc mysql 5.5.

SUNW-MSG-ID: SMF-8000-YX, TYPE: defect, VER: 1, SEVERITY: major
EVENT-TIME: Tue Nov  3 15:30:16 EST 2015
PLATFORM: IR2300, CSN: P1236040860, HOSTNAME: tardis
SOURCE: software-diagnosis, REV: 0.1
EVENT-ID: e3b438b9-d1a0-c5aa-a42f-c5c356055efa
DESC: A service failed - a method is failing in a retryable manner but 
too often.
   Refer to http://illumos.org/msg/SMF-8000-YX for more information.
AUTO-RESPONSE: The service has been placed into the maintenance state.
IMPACT: svc:/pkgsrc/mysql:default is unavailable.
REC-ACTION: Run 'svcs -xv svc:/pkgsrc/mysql:default' to determine the 
generic reason why the service failed, the location of any logfiles, and 
a list of other services impacted.

and from the logs:
[ Nov  3 15:30:08 Executing start method 
("/opt/local/lib/svc/method/mysqld start"). ]
/sbin/sh[1]: exec: /opt/local/lib/svc/method/mysqld: not found

Sure enough, it wasn't there.  I reinstalled mysql and everything is 
working again.

Gary

On 11/03/2015 10:56 AM, Dan McDonald wrote:
> Say hello to OmniOS r151016:
>
> 	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151016
>
> The big highlights include:
>
> 	- Userland now compiled with gcc5.1.
>
> 	- New and complete "illumos-tools" package available for more expedient illumos development
>
> 	- netperf and iperf now available for all of your network measuring needs.
>
> 	- Up to date with October illumos-gate
>
> 	- New installs get OpenSSH by default, and OpenSSH is now easier to switch to or from.  (Thanks to Lauri "lotheac" Tirkkonen for this!)
>
> OmniOS r151016 is the next Stable release.  r151014 now assumes its role as LTS.  (There will be an r151014 update later this week, with one bugfix from illumos-gate that needs to be brought back.)
>
> If you took advantage of linked-image zones in r151014, make sure you read the upgrade instructions.  You can do it more quickly than in the past, but it requires a bit of setup.
>
> Thank you to the OmniOS community for your feedback and support!
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3699 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151103/51e6fe9e/attachment-0001.bin>

From danmcd at omniti.com  Tue Nov  3 21:49:29 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 16:49:29 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
Message-ID: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>


> On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> 
> Hi Dan, list,
> 
> Something is going wrong for me with openssh, going from 151014 to 151016. I don't recall doing anything funny with SunSSH in the past. What am I doing wrong here?

The error is unfortunately misleading.

Please check your ms.omniti.com packages.  You can do this by uttering:

	pkg update entire at 11-0.151016

you will likely see a lot of ms.omniti.com packages that block you from updating "entire".  You will either have to uninstall those, or somehow else work around that.

One *possible* workaround is to uninstall "entire" from your BE (it's just a metapackage) prior to "pkg update".

Dan


From danmcd at omniti.com  Tue Nov  3 21:54:53 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 16:54:53 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
Message-ID: <F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>


> On Nov 3, 2015, at 4:49 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
> Please check your ms.omniti.com packages.  You can do this by uttering:
> 
> 	pkg update entire at 11-0.151016
> 
> you will likely see a lot of ms.omniti.com packages that block you from updating "entire".  You will either have to uninstall those, or somehow else work around that.

I've confirmed on one of my own setups that removing the blocking ms.omniti.com packages will cure what ails you.

I've also confirmed the relatively cheesy workaround of uninstalling "entire" also works.

Hope this helps,
Dan


From hasslerd at gmx.li  Tue Nov  3 22:17:39 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Tue, 03 Nov 2015 23:17:39 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
Message-ID: <56393283.3020706@gmx.li>

Hi,

I am facing upgrade problems, too.

Followed the instructions:
- detached all lipkg zones
- unset publisher omnios
- set publisher omnios (to r16)
- did the upgrade to r16
- rebooted

Everything worked as expected so far. However I cannot attach zones anymore.

# zoneadm -z <zonename> attach -u
gives the following error:

                 Installing: Using pre-existing data in zonepath
        Global zone version: entire at 11-0.151016:20151102T202622Z
    Non-Global zone version: entire at 11-0.151014:20150914T123242Z
                      Cache: Using /var/pkg/publisher.
   Updating non-global zone: Output follows
Updating package cache                           1/1
Creating Plan (Running solver): /ERROR: Could not update attaching zone
                     Result: Attach Failed.



If I try to manually update the zone with:
# pkg -R <zonepath>/root update
the following error is shown:

Creating Plan (Running solver): \
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to 
latest available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:

   pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z
 
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z
 
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20151102T183750Z
 
pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20151102T185924Z

The following indicates why the system cannot update to the latest version:

   No suitable version of required package 
pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z found:
     Reject:  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z
     Reason:  A version for 'require' dependency on 
pkg:/package/pkg at 0.5.11,5.11-0.151016 cannot be found


Any ideas how to solve this?



On 11/03/2015 10:54 PM, Dan McDonald wrote:
>
>> On Nov 3, 2015, at 4:49 PM, Dan McDonald <danmcd at omniti.com> wrote:
>>
>>
>> Please check your ms.omniti.com packages.  You can do this by uttering:
>>
>> 	pkg update entire at 11-0.151016
>>
>> you will likely see a lot of ms.omniti.com packages that block you from updating "entire".  You will either have to uninstall those, or somehow else work around that.
>
> I've confirmed on one of my own setups that removing the blocking ms.omniti.com packages will cure what ails you.
>
> I've also confirmed the relatively cheesy workaround of uninstalling "entire" also works.
>
> Hope this helps,
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From mir at miras.org  Tue Nov  3 23:07:35 2015
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 4 Nov 2015 00:07:35 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56393283.3020706@gmx.li>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
Message-ID: <20151104000735.7075fdc7@sleipner.datanom.net>

On Tue, 03 Nov 2015 23:17:39 +0100
Dominik Hassler <hasslerd at gmx.li> wrote:

> 
> The following indicates why the system cannot update to the latest version:
> 
>    No suitable version of required package pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z found:
>      Reject:  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z
>      Reason:  A version for 'require' dependency on pkg:/package/pkg at 0.5.11,5.11-0.151016 cannot be found
> 
> 
Are you able to upgrade pkg before doing pkg update?

-- 
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:
She always believed in the old adage -- leave them while you're looking
good. -- Anita Loos, "Gentlemen Prefer Blondes"
-------------- 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/20151104/ea877cf4/attachment.bin>

From hasslerd at gmx.li  Tue Nov  3 23:15:13 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Wed, 04 Nov 2015 00:15:13 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <20151104000735.7075fdc7@sleipner.datanom.net>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
Message-ID: <56394001.2040509@gmx.li>

no I can't:

pkg -R <zonepath>/root update pkg:/package/pkg at 0.5.11,5.11-0.151016
Creating Plan (Solver setup): |
pkg update: No matching version of package/pkg can be installed:
   Reject:  pkg://omnios/package/pkg at 0.5.11,5.11-0.151016:20151102T194048Z
   Reason:  All versions matching 'require' dependency 
pkg:/SUNWcs at 0.5.11,5.11-0.151016 are rejected
     Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151016:20151102T183755Z
     Reason:  This version is excluded by installed incorporation 
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151014:20150929T225300Z
              This version is excluded by installed incorporation 
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151014:20150402T174324Z
            Global zone has an older version of package: 
pkg://omnios/package/pkg at 0.5.11,5.11-0.151014:20150402T184307Z

in the GZ:
$ pkg list package/pkg
NAME (PUBLISHER)                                  VERSION 
      IFO
package/pkg                                       0.5.11-0.151016 
      i--



On 11/04/2015 12:07 AM, Michael Rasmussen wrote:
> On Tue, 03 Nov 2015 23:17:39 +0100
> Dominik Hassler <hasslerd at gmx.li> wrote:
>
>>
>> The following indicates why the system cannot update to the latest version:
>>
>>     No suitable version of required package pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z found:
>>       Reject:  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z
>>       Reason:  A version for 'require' dependency on pkg:/package/pkg at 0.5.11,5.11-0.151016 cannot be found
>>
>>
> Are you able to upgrade pkg before doing pkg update?
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From mir at miras.org  Tue Nov  3 23:57:08 2015
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 4 Nov 2015 00:57:08 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56394001.2040509@gmx.li>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
	<56394001.2040509@gmx.li>
Message-ID: <20151104005708.1a67c2d9@sleipner.datanom.net>

On Wed, 04 Nov 2015 00:15:13 +0100
Dominik Hassler <hasslerd at gmx.li> wrote:

>             Global zone has an older version of package: pkg://omnios/package/pkg at 0.5.11,5.11-0.151014:20150402T184307Z
> 
Strange. Didn't you just upgrade the global zone to r151016?

And you have changed publisher in zones to r151016?

-- 
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 no threads in a.b.p.erotica,  so there's no  gain in using a
threaded news reader.
(Unknown source)
-------------- 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/20151104/f26248fe/attachment-0001.bin>

From danmcd at omniti.com  Wed Nov  4 00:02:38 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 19:02:38 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56394001.2040509@gmx.li>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
	<56394001.2040509@gmx.li>
Message-ID: <0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>


> On Nov 3, 2015, at 6:15 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
> 
> no I can't:
> 
> pkg -R <zonepath>/root update pkg:/package/pkg at 0.5.11,5.11-0.151016
> Creating Plan (Solver setup): |
> pkg update: No matching version of package/pkg can be installed:
>  Reject:  pkg://omnios/package/pkg at 0.5.11,5.11-0.151016:20151102T194048Z
>  Reason:  All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151016 are rejected
>    Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151016:20151102T183755Z
>    Reason:  This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151014:20150929T225300Z
>             This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151014:20150402T174324Z
>           Global zone has an older version of package: pkg://omnios/package/pkg at 0.5.11,5.11-0.151014:20150402T184307Z
> 
> in the GZ:
> $ pkg list package/pkg
> NAME (PUBLISHER)                                  VERSION      IFO
> package/pkg                                       0.5.11-0.151016      i--

What's the publisher for <zonepath>/root ?

Dan


From hasslerd at gmx.li  Wed Nov  4 00:17:21 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Wed, 04 Nov 2015 01:17:21 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
	<56394001.2040509@gmx.li>
	<0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>
Message-ID: <56394E91.9000702@gmx.li>

when the first attach failed I reset the publishers in the NGZ manually, 
however attach/pkg update still failed.

Rebooted now into the old r14 backup BE, attached the zones and am using 
the lipkg update procedure now. Looking good so far. Will report back 
once successfully finished.


On 11/04/2015 01:02 AM, Dan McDonald wrote:
>
>> On Nov 3, 2015, at 6:15 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>
>> no I can't:
>>
>> pkg -R <zonepath>/root update pkg:/package/pkg at 0.5.11,5.11-0.151016
>> Creating Plan (Solver setup): |
>> pkg update: No matching version of package/pkg can be installed:
>>   Reject:  pkg://omnios/package/pkg at 0.5.11,5.11-0.151016:20151102T194048Z
>>   Reason:  All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151016 are rejected
>>     Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151016:20151102T183755Z
>>     Reason:  This version is excluded by installed incorporation pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151014:20150929T225300Z
>>              This version is excluded by installed incorporation pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151014:20150402T174324Z
>>            Global zone has an older version of package: pkg://omnios/package/pkg at 0.5.11,5.11-0.151014:20150402T184307Z
>>
>> in the GZ:
>> $ pkg list package/pkg
>> NAME (PUBLISHER)                                  VERSION      IFO
>> package/pkg                                       0.5.11-0.151016      i--
>
> What's the publisher for <zonepath>/root ?
>
> Dan
>

From danmcd at omniti.com  Wed Nov  4 00:21:08 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 19:21:08 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56394E91.9000702@gmx.li>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
	<56394001.2040509@gmx.li>
	<0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>
	<56394E91.9000702@gmx.li>
Message-ID: <ED453DBE-9176-4B51-B6AC-BD08EB6DC6E3@omniti.com>


> On Nov 3, 2015, at 7:17 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
> 
> when the first attach failed I reset the publishers in the NGZ manually, however attach/pkg update still failed.
> 
> Rebooted now into the old r14 backup BE, attached the zones and am using the lipkg update procedure now. Looking good so far. Will report back once successfully finished.

If you have any ms.omniti.com packages, watch out.  They often block upgrades.

Dan


From hasslerd at gmx.li  Wed Nov  4 00:24:28 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Wed, 04 Nov 2015 01:24:28 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <ED453DBE-9176-4B51-B6AC-BD08EB6DC6E3@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>
	<56393283.3020706@gmx.li>
	<20151104000735.7075fdc7@sleipner.datanom.net>
	<56394001.2040509@gmx.li>
	<0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>
	<56394E91.9000702@gmx.li>
	<ED453DBE-9176-4B51-B6AC-BD08EB6DC6E3@omniti.com>
Message-ID: <5639503C.2020304@gmx.li>

I have no ms.omniti.com packages. Just a couple of own packages which 
are not depending on a particular release.

On 11/04/2015 01:21 AM, Dan McDonald wrote:
>
>> On Nov 3, 2015, at 7:17 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>
>> when the first attach failed I reset the publishers in the NGZ manually, however attach/pkg update still failed.
>>
>> Rebooted now into the old r14 backup BE, attached the zones and am using the lipkg update procedure now. Looking good so far. Will report back once successfully finished.
>
> If you have any ms.omniti.com packages, watch out.  They often block upgrades.
>
> Dan
>

From omnios at citrus-it.net  Wed Nov  4 00:31:32 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 4 Nov 2015 00:31:32 +0000 (UTC)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
Message-ID: <alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>


Hi Dan,

Last year you relaxed a dependency in the mailwrapper manifest so that
sendmail wasn't a mandatory package in OmniOS. However, I notice that
a sendmail dependency has now appeared in entire - sometime between me
testing an upgrade with bloody a couple of weeks ago and r151016 appearing.
(I can't check the history as I'm getting timeouts accessing the
 repository at the moment).

Any chance this new dependency could be similarly weakened or backed-out?
IIRC, there were a few other people who wanted to be able to remove
the sendmail MTA entirely.

Thanks,

Andy

On Mon, 9 Mar 2015, Dan McDonald wrote:
;
; Tell me, would weakening the requirement of sendmail by mailwrapper help?
;
; diff --git a/usr/src/pkg/manifests/system-network-mailwrapper.mf b/usr/src/pkg/manifests/system-network-mailwrapper.mf
; index fa855da..21cc0b7 100644
; --- a/usr/src/pkg/manifests/system-network-mailwrapper.mf
; +++ b/usr/src/pkg/manifests/system-network-mailwrapper.mf
; @@ -42,4 +42,4 @@ link path=usr/sbin/newaliases mediator=mta mediator-implementation=mailwrapper \
;      target=../lib/mailwrapper
;  link path=usr/sbin/sendmail mediator=mta mediator-implementation=mailwrapper \
;      target=../lib/mailwrapper
; -depend fmri=service/network/smtp/sendmail type=require
; +depend fmri=service/network/smtp/sendmail type=optional
;
; This keeps the spirit of the change, but doesn't trip up folks who want their own sendmail (even if they are technically violating KYSTY in their version!  ;) ).

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From danmcd at omniti.com  Wed Nov  4 00:33:40 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 3 Nov 2015 19:33:40 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
Message-ID: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>


> On Nov 3, 2015, at 7:31 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> 
> Hi Dan,
> 
> Last year you relaxed a dependency in the mailwrapper manifest so that
> sendmail wasn't a mandatory package in OmniOS. However, I notice that
> a sendmail dependency has now appeared in entire - sometime between me
> testing an upgrade with bloody a couple of weeks ago and r151016 appearing.
> (I can't check the history as I'm getting timeouts accessing the
> repository at the moment).
> 
> Any chance this new dependency could be similarly weakened or backed-out?
> IIRC, there were a few other people who wanted to be able to remove
> the sendmail MTA entirely.

https://github.com/omniti-labs/omnios-build/issues/69

We may need to weaken "require" to something else.  I know the bug filer is on this list.  I'd appreciate a dialogue here on this subject.

Thanks,
Dan


From hasslerd at gmx.li  Wed Nov  4 01:13:10 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Wed, 04 Nov 2015 02:13:10 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56394E91.9000702@gmx.li>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>	<F802A0C3-8E19-4CD5-864A-D11D9B29F7C8@omniti.com>	<56393283.3020706@gmx.li>	<20151104000735.7075fdc7@sleipner.datanom.net>	<56394001.2040509@gmx.li>	<0A6B2332-333F-4CD3-99B9-941ED4E829AF@omniti.com>
	<56394E91.9000702@gmx.li>
Message-ID: <56395BA6.6040609@gmx.li>

performing the upgrade using the "lipkg procedure" worked with no issues.

On 11/04/2015 01:17 AM, Dominik Hassler wrote:
> when the first attach failed I reset the publishers in the NGZ manually,
> however attach/pkg update still failed.
>
> Rebooted now into the old r14 backup BE, attached the zones and am using
> the lipkg update procedure now. Looking good so far. Will report back
> once successfully finished.
>
>
> On 11/04/2015 01:02 AM, Dan McDonald wrote:
>>
>>> On Nov 3, 2015, at 6:15 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>
>>> no I can't:
>>>
>>> pkg -R <zonepath>/root update pkg:/package/pkg at 0.5.11,5.11-0.151016
>>> Creating Plan (Solver setup): |
>>> pkg update: No matching version of package/pkg can be installed:
>>>   Reject:
>>> pkg://omnios/package/pkg at 0.5.11,5.11-0.151016:20151102T194048Z
>>>   Reason:  All versions matching 'require' dependency
>>> pkg:/SUNWcs at 0.5.11,5.11-0.151016 are rejected
>>>     Reject:  pkg://omnios/SUNWcs at 0.5.11,5.11-0.151016:20151102T183755Z
>>>     Reason:  This version is excluded by installed incorporation
>>> pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151014:20150929T225300Z
>>>
>>>              This version is excluded by installed incorporation
>>> pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151014:20150402T174324Z
>>>
>>>            Global zone has an older version of package:
>>> pkg://omnios/package/pkg at 0.5.11,5.11-0.151014:20150402T184307Z
>>>
>>> in the GZ:
>>> $ pkg list package/pkg
>>> NAME (PUBLISHER)                                  VERSION      IFO
>>> package/pkg
>>> 0.5.11-0.151016      i--
>>
>> What's the publisher for <zonepath>/root ?
>>
>> Dan
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From henson at acm.org  Wed Nov  4 02:39:18 2015
From: henson at acm.org (Paul B. Henson)
Date: Tue, 03 Nov 2015 18:39:18 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
Message-ID: <20151104023917.GA3405@bender.unx.cpp.edu>

On Tue, Nov 03, 2015 at 07:33:40PM -0500, Dan McDonald wrote:

> We may need to weaken "require" to something else.  I know the bug
> filer is on this list.  I'd appreciate a dialogue here on this
> subject.

We don't use sendmail. I remember piping up when sendmail became a
requirement of 014 during its bloody phase, so I will restate -- please
don't make sendmail a hard dependency :(. What's the point of an
interposer allowing the use of whatever mail system you want if you're
forced to install one you don't want 8-/. Generally on operating systems
that allow multiple options of a specific service you add on the ones
you want after the base install. I'd say the box in the bug report
simply hadn't been fully configured yet.

Honestly, I can't understand why anyone would *choose* to use sendmail
nowadays ;), if you want to install an MTA in the base how about you
package up postfix :)... We're currently running it from pkgsrc.


From gary at genashor.com  Wed Nov  4 02:56:21 2015
From: gary at genashor.com (Gary Gendel)
Date: Tue, 3 Nov 2015 21:56:21 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104023917.GA3405@bender.unx.cpp.edu>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
Message-ID: <563973D5.1060002@genashor.com>

Though in principal I agree with you.  Having sendmail installed but not 
enabled only wastes a little disk space.  This isn't a showstopper for 
me.  Before mailwrapper it was a royal nightmare.

On 11/3/2015 9:39 PM, Paul B. Henson wrote:
> On Tue, Nov 03, 2015 at 07:33:40PM -0500, Dan McDonald wrote:
>
>> We may need to weaken "require" to something else.  I know the bug
>> filer is on this list.  I'd appreciate a dialogue here on this
>> subject.
> We don't use sendmail. I remember piping up when sendmail became a
> requirement of 014 during its bloody phase, so I will restate -- please
> don't make sendmail a hard dependency :(. What's the point of an
> interposer allowing the use of whatever mail system you want if you're
> forced to install one you don't want 8-/. Generally on operating systems
> that allow multiple options of a specific service you add on the ones
> you want after the base install. I'd say the box in the bug report
> simply hadn't been fully configured yet.
>
> Honestly, I can't understand why anyone would *choose* to use sendmail
> nowadays ;), if you want to install an MTA in the base how about you
> package up postfix :)... We're currently running it from pkgsrc.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



From lotheac at iki.fi  Wed Nov  4 08:00:45 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 4 Nov 2015 10:00:45 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104023917.GA3405@bender.unx.cpp.edu>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
Message-ID: <20151104080045.GA24984@gutsman.lotheac.fi>

On Tue, Nov 03 2015 18:39:18 -0800, Paul B. Henson wrote:
> On Tue, Nov 03, 2015 at 07:33:40PM -0500, Dan McDonald wrote:
> 
> > We may need to weaken "require" to something else.  I know the bug
> > filer is on this list.  I'd appreciate a dialogue here on this
> > subject.
> 
> We don't use sendmail. I remember piping up when sendmail became a
> requirement of 014 during its bloody phase, so I will restate -- please
> don't make sendmail a hard dependency :(. What's the point of an
> interposer allowing the use of whatever mail system you want if you're
> forced to install one you don't want 8-/. Generally on operating systems
> that allow multiple options of a specific service you add on the ones
> you want after the base install. I'd say the box in the bug report
> simply hadn't been fully configured yet.

I reported the issue because I think it's very important that OmniOS
ships with a working MTA out of the box, because things like cron do
need one. AIUI, the point of mailwrapper and the added IPS mediations is
that you can choose to install another one (that is not necessarily
shipped by the OS vendor, or even shipped as an IPS package) and use it
by default without the package manager fighting you.

You don't have to *use* sendmail. I don't really understand why you're
objecting to its mere presence on disk; it's not very large.

> Honestly, I can't understand why anyone would *choose* to use sendmail
> nowadays ;), if you want to install an MTA in the base how about you
> package up postfix :)... We're currently running it from pkgsrc.

OmniOS at present only ships one MTA choice, and that happens to be
sendmail. I would not mind that being some other MTA, but I think there
needs to be one in the base install.

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From gate03 at landcroft.co.uk  Wed Nov  4 09:49:43 2015
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Wed, 4 Nov 2015 19:49:43 +1000
Subject: [OmniOS-discuss] OmniOS stops acting as a DHCP client
Message-ID: <20151104194943.3faa0777@coomera>

This is one of those instances where I'm going to leave out some
relevant fact but I'll try to put in all the factors.

TL;DR OmniOS permanently refuses to be a DHCP client.

My home server has two interfaces which show up as e1000g{0,1}.
e1000g0 is connected to the cable router provided by my ISP (Optus).

While I was away to-day, the server 'lost' the interface;  i.e.,
netstat -r did not show any ref. to e1000g0.  So I took it down and
brought it up again:

# ipadm delete-addr  e1000g0/v4
# ipadm delete-if e1000g0
# ipadm create-if e1000g0
# ipadm create-addr -T dhcp e1000g0/v4

Those last two commands were how I set up the interface on
post-installation configuration.  However, now that last command hangs
for a couple of minutes before dhcpagent reports a timeout.

The workaround is to assign an address statically:

# ipadm delete-addr  e1000g0/v4
# ipadm create-addr -T static -a 192.168.0.9 e1000g0/v4

This happened just the same with r151013 but I never got around to
investigating it.

A laptop, connected to the router, is able to obtain an address from
the router.

The paranoid in me wonders if Optus have loaded special firmware onto
their router which has decided that since I'm not running some version
of Mess Windows, for my own protection I won't be given an IP address.

I repeat:  r151014 has been getting its IP from the router's DHCP
server for about four weeks and has just stopped doing so
to-day, without intervention from me.

Any ideas?

______________
Michael Mounteney

From hasslerd at gmx.li  Wed Nov  4 12:05:39 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Wed, 4 Nov 2015 13:05:39 +0100
Subject: [OmniOS-discuss] OmniOS r151016: perl build broken?
Message-ID: <trinity-0549e2c0-2dd3-4f14-b8f5-5516adbf3455-1446638738972@3capp-gmx-bs26>

Hi Dan,

after upgrading to r16 I found that znapzend (pure perl program) got stuck in maintenance mode. The service status log file revealed the following:
"EINPROGRESS" is not exported by the Errno module

Checking the Errno.pm (core perl module) I found that the %err hash as well as the %EXPORT_TAGS hash are empty:
BEGIN {
    %err = (
    );
...
}

...

our %EXPORT_TAGS = (
    POSIX => [qw(
    )]
);

The Errno.pm build depends on the errno.h header file (/usr/include/errno.h) which I found to be present on some of my OmniOS r16 boxes but not on all of them.

As a temporary fix I copied the hashes from another Errno.pm on a non r16 system.

znapzend users be warned that upgrading to OmniOS r16 will currently stop znapzend from working.

Dan, could you please check the presence of errno.h on your building box as well as the build of Errno.pm?

Thank you,
Dominik




From sequoiamobil at gmx.net  Wed Nov  4 12:12:20 2015
From: sequoiamobil at gmx.net (Sebastian Gabler)
Date: Wed, 4 Nov 2015 13:12:20 +0100
Subject: [OmniOS-discuss] OmniOS r151016 Release notes
In-Reply-To: <mailman.1550.1446599595.63303.omnios-discuss@lists.omniti.com>
References: <mailman.1550.1446599595.63303.omnios-discuss@lists.omniti.com>
Message-ID: <5639F624.9050602@gmx.net>

To whom it may concern (assume it's Dan):

I am missing the release notes for latest stable on 
http://omnios.omniti.com/wiki.php/ReleaseNotes/

TIA

Sebastian

From lotheac at iki.fi  Wed Nov  4 12:30:45 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 4 Nov 2015 14:30:45 +0200
Subject: [OmniOS-discuss] OmniOS r151016: perl build broken?
In-Reply-To: <trinity-0549e2c0-2dd3-4f14-b8f5-5516adbf3455-1446638738972@3capp-gmx-bs26>
References: <trinity-0549e2c0-2dd3-4f14-b8f5-5516adbf3455-1446638738972@3capp-gmx-bs26>
Message-ID: <20151104123045.GB24984@gutsman.lotheac.fi>

On Wed, Nov 04 2015 13:05:39 +0100, Dominik Hassler wrote:
> after upgrading to r16 I found that znapzend (pure perl program) got stuck in maintenance mode. The service status log file revealed the following:
> "EINPROGRESS" is not exported by the Errno module
> 
> Checking the Errno.pm (core perl module) I found that the %err hash as well as the %EXPORT_TAGS hash are empty:
> BEGIN {
>     %err = (
>     );
> ...
> }
> 
> ...
> 
> our %EXPORT_TAGS = (
>     POSIX => [qw(
>     )]
> );
> 
> The Errno.pm build depends on the errno.h header file
> (/usr/include/errno.h) which I found to be present on some of my
> OmniOS r16 boxes but not on all of them.

This issue is gcc5 related (there was one just like it in zsh,
actually). Upstream perl fix:
https://github.com/Perl/perl5/commit/816b056ffb99ae54642320e20dc30a59fd1effef

> As a temporary fix I copied the hashes from another Errno.pm on a non r16 system.
> 
> znapzend users be warned that upgrading to OmniOS r16 will currently stop znapzend from working.

Only if using the system perl for znapzend, my znapzend from
pkg.niksula.hut.fi works fine on 151016 ;)

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From danmcd at omniti.com  Wed Nov  4 12:46:17 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 07:46:17 -0500
Subject: [OmniOS-discuss] OmniOS r151016: perl build broken?
In-Reply-To: <20151104123045.GB24984@gutsman.lotheac.fi>
References: <trinity-0549e2c0-2dd3-4f14-b8f5-5516adbf3455-1446638738972@3capp-gmx-bs26>
	<20151104123045.GB24984@gutsman.lotheac.fi>
Message-ID: <6F79DD03-7089-4148-8171-6002714D23E9@omniti.com>


> On Nov 4, 2015, at 7:30 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
> 
> 
> This issue is gcc5 related (there was one just like it in zsh,
> actually). Upstream perl fix:
> https://github.com/Perl/perl5/commit/816b056ffb99ae54642320e20dc30a59fd1effef

This is something I can drop as a patches/ entry to perl on omnios-build, modulo one nit.

I'm attaching the modified patch that I'd like Dominik to directly apply to the stock 016 Errno.pm and see if it cures what ails him.

I'm testing the Perl build right now, and will likely commit a change as soon as I get confirmation from Dominik, I'll spin & update.

Dan


From lists at marzocchi.net  Wed Nov  4 12:51:49 2015
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Wed, 04 Nov 2015 13:51:49 +0100
Subject: [OmniOS-discuss] Fwd: Re:  OmniOS r151016: perl build broken?
In-Reply-To: <7FE484F2-62E2-47A4-8483-EE8D062C726B@marzocchi.net>
References: <7FE484F2-62E2-47A4-8483-EE8D062C726B@marzocchi.net>
Message-ID: <FD2314D0-E203-4C9C-B11A-EC9A1E6BEF2B@marzocchi.net>



Compiling Perl is also quite simple, for my scripts and for znapzend I installed a version in /opt and never had issues. 




Il 04 novembre 2015 13:30:45 CET, Lauri Tirkkonen <lotheac at iki.fi> ha scritto:
>On Wed, Nov 04 2015 13:05:39 +0100, Dominik Hassler wrote:
>> after upgrading to r16 I found that znapzend (pure perl program) got
>stuck in maintenance mode. The service status log file revealed the
>following:
>> "EINPROGRESS" is not exported by the Errno module
>> 
>> Checking the Errno.pm (core perl module) I found that the %err hash
>as well as the %EXPORT_TAGS hash are empty:
>> BEGIN {
>>     %err = (
>>     );
>> ...
>> }
>> 
>> ...
>> 
>> our %EXPORT_TAGS = (
>>     POSIX => [qw(
>>     )]
>> );
>> 
>> The Errno.pm build depends on the errno.h header file
>> (/usr/include/errno.h) which I found to be present on some of my
>> OmniOS r16 boxes but not on all of them.
>
>This issue is gcc5 related (there was one just like it in zsh,
>actually). Upstream perl fix:
>https://github.com/Perl/perl5/commit/816b056ffb99ae54642320e20dc30a59fd1effef
>
>> As a temporary fix I copied the hashes from another Errno.pm on a non
>r16 system.
>> 
>> znapzend users be warned that upgrading to OmniOS r16 will currently
>stop znapzend from working.
>
>Only if using the system perl for znapzend, my znapzend from
>pkg.niksula.hut.fi works fine on 151016 ;)
>
>-- 
>Lauri Tirkkonen | lotheac @ IRCnet
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss


From danmcd at omniti.com  Wed Nov  4 12:56:15 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 07:56:15 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104080045.GA24984@gutsman.lotheac.fi>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
Message-ID: <ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>

Does the *presence* of sendmail in a default install actually prevent folks from using their preferred MTAs with the mediator (which still works from what I can tell)?

If indeed this is just about the sendmail bits being present, I have to say they stay, because we need an MTA out of the box, even a weak one, because of cron, nightly, and other bits.

If this blocks folks from configuring their systems, then I'm more willing to address this somehow.  IF (big IF) I end up re-yanking sendmail (undoing omnios-build issue #69), I will end up placing it in illumos-tools.

Dan


From danmcd at omniti.com  Wed Nov  4 12:59:16 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 07:59:16 -0500
Subject: [OmniOS-discuss] OmniOS stops acting as a DHCP client
In-Reply-To: <20151104194943.3faa0777@coomera>
References: <20151104194943.3faa0777@coomera>
Message-ID: <9B55395C-B3F8-4A6D-B77C-B2D2910D6AEE@omniti.com>


> On Nov 4, 2015, at 4:49 AM, Michael Mounteney <gate03 at landcroft.co.uk> wrote:
> 
> This is one of those instances where I'm going to leave out some
> relevant fact but I'll try to put in all the factors.
> 
> TL;DR OmniOS permanently refuses to be a DHCP client.

I'd highly recommend monitoring the DHCP traffic and sharing it here:

	snoop -o dhcp-traffic udp port 67 or udp port 68

Analyzing the traffic would be helpful here.

And you said you're seeing this in 014 and even its prior bloody 013.  006 is still available for the next 4-6 months -- does that {mis,}behave the same way?  And what about other illumos distros?  This problem should be consistent across them, as we make no client-side DHCP changes in OmniOS.

Dan


From lotheac at iki.fi  Wed Nov  4 13:01:06 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 4 Nov 2015 15:01:06 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
Message-ID: <20151104130106.GD24984@gutsman.lotheac.fi>

On Wed, Nov 04 2015 07:56:15 -0500, Dan McDonald wrote:
> Does the *presence* of sendmail in a default install actually prevent
> folks from using their preferred MTAs with the mediator (which still
> works from what I can tell)?

No. OmniOS being an IPS distro there are two ways to switch to a
different MTA: the mediator (if the other MTA is an IPS package which
also participates in the mediator) and mailwrapper configuration
(otherwise).

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From danmcd at omniti.com  Wed Nov  4 13:01:38 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 08:01:38 -0500
Subject: [OmniOS-discuss] OmniOS r151016 Release notes
In-Reply-To: <5639F624.9050602@gmx.net>
References: <mailman.1550.1446599595.63303.omnios-discuss@lists.omniti.com>
	<5639F624.9050602@gmx.net>
Message-ID: <EFFE3316-D0AF-43F4-9CC2-FA881E170378@omniti.com>


> On Nov 4, 2015, at 7:12 AM, Sebastian Gabler <sequoiamobil at gmx.net> wrote:
> 
> To whom it may concern (assume it's Dan):
> 
> I am missing the release notes for latest stable on http://omnios.omniti.com/wiki.php/ReleaseNotes/

Shoot!  I knew I forgot something...

	http://omnios.omniti.com/changeset.php/default/wiki/5379e90c53317a3372e910a42d6320aaf1ccf31c

Thank you!
Dan


From danmcd at omniti.com  Wed Nov  4 13:05:36 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 08:05:36 -0500
Subject: [OmniOS-discuss] OmniOS r151016: perl build broken?
In-Reply-To: <6F79DD03-7089-4148-8171-6002714D23E9@omniti.com>
References: <trinity-0549e2c0-2dd3-4f14-b8f5-5516adbf3455-1446638738972@3capp-gmx-bs26>
	<20151104123045.GB24984@gutsman.lotheac.fi>
	<6F79DD03-7089-4148-8171-6002714D23E9@omniti.com>
Message-ID: <15B37B5D-5735-4E35-BC6B-30BEC3820C76@omniti.com>


> On Nov 4, 2015, at 7:46 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> I'm testing the Perl build right now, and will likely commit a change as soon as I get confirmation from Dominik, I'll spin & update.

It built, and I think successfully.  Here's a webrev with my omnios-build changes:

	http://kebe.com/~danmcd/webrevs/perl-errno/

And here are diffs from the build proto area (fixed) vs. what's installed (broken):

bloody(build_danmcd/runtime_perl-5161_pkg)[1]% diff -u {,.}/usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/Errno.pm
--- /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/Errno.pm	Wed Jun 17 10:45:24 2015
+++ ./usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int/Errno.pm	Wed Nov  4 07:44:27 2015
@@ -20,6 +20,128 @@
 
 BEGIN {
     %err = (
+	EPERM => 1,
+	ENOENT => 2,
+	ESRCH => 3,
+	EINTR => 4,
+	EIO => 5,
+	ENXIO => 6,
+	E2BIG => 7,
+	ENOEXEC => 8,
+	EBADF => 9,
+	ECHILD => 10,
+	EWOULDBLOCK => 11,
+	EAGAIN => 11,
+	ENOMEM => 12,
+	EACCES => 13,
+	EFAULT => 14,
+	ENOTBLK => 15,
+	EBUSY => 16,
+	EEXIST => 17,
+	EXDEV => 18,
+	ENODEV => 19,
+	ENOTDIR => 20,
+	EISDIR => 21,
+	EINVAL => 22,
+	ENFILE => 23,
+	EMFILE => 24,
+	ENOTTY => 25,
+	ETXTBSY => 26,
+	EFBIG => 27,
+	ENOSPC => 28,
+	ESPIPE => 29,
+	EROFS => 30,
+	EMLINK => 31,
+	EPIPE => 32,
+	EDOM => 33,
+	ERANGE => 34,
+	ENOMSG => 35,
+	EIDRM => 36,
+	ECHRNG => 37,
+	EL2NSYNC => 38,
+	EL3HLT => 39,
+	EL3RST => 40,
+	ELNRNG => 41,
+	EUNATCH => 42,
+	ENOCSI => 43,
+	EL2HLT => 44,
+	EDEADLK => 45,
+	ENOLCK => 46,
+	ECANCELED => 47,
+	ENOTSUP => 48,
+	EDQUOT => 49,
+	EBADE => 50,
+	EBADR => 51,
+	EXFULL => 52,
+	ENOANO => 53,
+	EBADRQC => 54,
+	EBADSLT => 55,
+	EDEADLOCK => 56,
+	EBFONT => 57,
+	EOWNERDEAD => 58,
+	ENOTRECOVERABLE => 59,
+	ENOSTR => 60,
+	ENODATA => 61,
+	ETIME => 62,
+	ENOSR => 63,
+	ENONET => 64,
+	ENOPKG => 65,
+	EREMOTE => 66,
+	ENOLINK => 67,
+	EADV => 68,
+	ESRMNT => 69,
+	ECOMM => 70,
+	EPROTO => 71,
+	ELOCKUNMAPPED => 72,
+	ENOTACTIVE => 73,
+	EMULTIHOP => 74,
+	EBADMSG => 77,
+	ENAMETOOLONG => 78,
+	EOVERFLOW => 79,
+	ENOTUNIQ => 80,
+	EBADFD => 81,
+	EREMCHG => 82,
+	ELIBACC => 83,
+	ELIBBAD => 84,
+	ELIBSCN => 85,
+	ELIBMAX => 86,
+	ELIBEXEC => 87,
+	EILSEQ => 88,
+	ENOSYS => 89,
+	ELOOP => 90,
+	ERESTART => 91,
+	ESTRPIPE => 92,
+	ENOTEMPTY => 93,
+	EUSERS => 94,
+	ENOTSOCK => 95,
+	EDESTADDRREQ => 96,
+	EMSGSIZE => 97,
+	EPROTOTYPE => 98,
+	ENOPROTOOPT => 99,
+	EPROTONOSUPPORT => 120,
+	ESOCKTNOSUPPORT => 121,
+	EOPNOTSUPP => 122,
+	EPFNOSUPPORT => 123,
+	EAFNOSUPPORT => 124,
+	EADDRINUSE => 125,
+	EADDRNOTAVAIL => 126,
+	ENETDOWN => 127,
+	ENETUNREACH => 128,
+	ENETRESET => 129,
+	ECONNABORTED => 130,
+	ECONNRESET => 131,
+	ENOBUFS => 132,
+	EISCONN => 133,
+	ENOTCONN => 134,
+	ESHUTDOWN => 143,
+	ETOOMANYREFS => 144,
+	ETIMEDOUT => 145,
+	ECONNREFUSED => 146,
+	EHOSTDOWN => 147,
+	EHOSTUNREACH => 148,
+	EALREADY => 149,
+	EINPROGRESS => 150,
+	ESTALE => 151,
     );
     # Generate proxy constant subroutines for all the values.
     # Well, almost all the values. Unfortunately we can't assume that at this
@@ -46,7 +168,16 @@
 
 our %EXPORT_TAGS = (
     POSIX => [qw(
-	
+	E2BIG EACCES EADDRINUSE EADDRNOTAVAIL EAFNOSUPPORT EAGAIN EALREADY
+	EBADF EBUSY ECHILD ECONNABORTED ECONNREFUSED ECONNRESET EDEADLK
+	EDESTADDRREQ EDOM EDQUOT EEXIST EFAULT EFBIG EHOSTDOWN EHOSTUNREACH
+	EINPROGRESS EINTR EINVAL EIO EISCONN EISDIR ELOOP EMFILE EMLINK
+	EMSGSIZE ENAMETOOLONG ENETDOWN ENETRESET ENETUNREACH ENFILE ENOBUFS
+	ENODEV ENOENT ENOEXEC ENOLCK ENOMEM ENOPROTOOPT ENOSPC ENOSYS ENOTBLK
+	ENOTCONN ENOTDIR ENOTEMPTY ENOTSOCK ENOTTY ENXIO EOPNOTSUPP EPERM
+	EPFNOSUPPORT EPIPE EPROTONOSUPPORT EPROTOTYPE ERANGE EREMOTE ERESTART
+	EROFS ESHUTDOWN ESOCKTNOSUPPORT ESPIPE ESRCH ESTALE ETIMEDOUT
+	ETOOMANYREFS ETXTBSY EUSERS EWOULDBLOCK EXDEV
     )]
 );
 
bloody(build_danmcd/runtime_perl-5161_pkg)[1]% 


Hope this helps!
Dan


From contact at jacobvosmaer.nl  Wed Nov  4 18:13:42 2015
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Wed, 4 Nov 2015 19:13:42 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
Message-ID: <CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>

Thanks Dan, uninstalling all ms.omniti.com packages made the 151016 upgrade
go through. Now I just have to figure out how to install Ruby for myself.

2015-11-03 22:49 GMT+01:00 Dan McDonald <danmcd at omniti.com>:

>
> > On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer <contact at jacobvosmaer.nl>
> wrote:
> >
> > Hi Dan, list,
> >
> > Something is going wrong for me with openssh, going from 151014 to
> 151016. I don't recall doing anything funny with SunSSH in the past. What
> am I doing wrong here?
>
> The error is unfortunately misleading.
>
> Please check your ms.omniti.com packages.  You can do this by uttering:
>
>         pkg update entire at 11-0.151016
>
> you will likely see a lot of ms.omniti.com packages that block you from
> updating "entire".  You will either have to uninstall those, or somehow
> else work around that.
>
> One *possible* workaround is to uninstall "entire" from your BE (it's just
> a metapackage) prior to "pkg update".
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151104/f1b1a7a7/attachment.html>

From gary at genashor.com  Wed Nov  4 18:22:04 2015
From: gary at genashor.com (Gary Gendel)
Date: Wed, 4 Nov 2015 13:22:04 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>
Message-ID: <563A4CCC.4030200@genashor.com>

Jacob,

I suggest getting it from pkgsrc 
https://pkgsrc.joyent.com/install-on-illumos/

There are several Ruby versions available

Gary

On 11/04/2015 01:13 PM, Jacob Vosmaer wrote:
> Thanks Dan, uninstalling all ms.omniti.com <http://ms.omniti.com> 
> packages made the 151016 upgrade go through. Now I just have to figure 
> out how to install Ruby for myself.
>
> 2015-11-03 22:49 GMT+01:00 Dan McDonald <danmcd at omniti.com 
> <mailto:danmcd at omniti.com>>:
>
>
>     > On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer
>     <contact at jacobvosmaer.nl <mailto:contact at jacobvosmaer.nl>> wrote:
>     >
>     > Hi Dan, list,
>     >
>     > Something is going wrong for me with openssh, going from 151014
>     to 151016. I don't recall doing anything funny with SunSSH in the
>     past. What am I doing wrong here?
>
>     The error is unfortunately misleading.
>
>     Please check your ms.omniti.com <http://ms.omniti.com> packages. 
>     You can do this by uttering:
>
>             pkg update entire at 11-0.151016
>
>     you will likely see a lot of ms.omniti.com <http://ms.omniti.com>
>     packages that block you from updating "entire".  You will either
>     have to uninstall those, or somehow else work around that.
>
>     One *possible* workaround is to uninstall "entire" from your BE
>     (it's just a metapackage) prior to "pkg update".
>
>     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/20151104/379a3de6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3699 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151104/379a3de6/attachment-0001.bin>

From henson at acm.org  Wed Nov  4 20:07:14 2015
From: henson at acm.org (Paul B. Henson)
Date: Wed, 04 Nov 2015 12:07:14 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104080045.GA24984@gutsman.lotheac.fi>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
Message-ID: <20151104200713.GC3405@bender.unx.cpp.edu>

On Wed, Nov 04, 2015 at 10:00:45AM +0200, Lauri Tirkkonen wrote:

> I reported the issue because I think it's very important that OmniOS
> ships with a working MTA out of the box, because things like cron do
> need one.

An "out of the box" omnios install is basically unusable. There's a root
user with a blank password and no networking configured (unless you've
customized the install). After the basic install, you need to configure
the box to make it usable for your purposes (whether that's manually
done or via some automated configuration process). IMHO, installing and
configuring your mailer of choice should be part of the post-install
configure/customize process.

> You don't have to *use* sendmail. I don't really understand why you're
> objecting to its mere presence on disk; it's not very large.

I'm a purist, it's a matter of principle, and forcibly bundling
unnecessary components violates what I consider the omnios philosophy of
minimalization.

> OmniOS at present only ships one MTA choice, and that happens to be
> sendmail. I would not mind that being some other MTA, but I think there
> needs to be one in the base install.

We'll have to agree to disagree on whether or not a (specific) MTA is
considered a core component of an OS. While I don't think an MTA should
be installed by default, if one is I think a user should be able to
remove it and replace it with another, not have it cast in stone and
hiding in the shadows under a tarp pretending it doesn't exist.

Although it seems we'd both be happy if Dan ditched archaic sendmail and
bundled postfix ;)...


From info at houseofancients.nl  Wed Nov  4 20:20:10 2015
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Wed, 4 Nov 2015 20:20:10 +0000
Subject: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7
In-Reply-To: <mailman.1557.1446661329.63303.omnios-discuss@lists.omniti.com>
References: <mailman.1557.1446661329.63303.omnios-discuss@lists.omniti.com>
Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC9056988@vEX01.mindstorm-internet.local>

Hi All,



While trying to update 151014 to 151016.



Creating Plan (Running solver): /

pkg update: No solution was found to satisfy constraints

Plan Creation: Package solver has not found a solution to update to latest available versions.

This may indicate an overly constrained set of packages are installed.



latest incorporations:



  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20151102T183750Z

  pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z

  pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20151102T185924Z

  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z



The following indicates why the system cannot update to the latest version:



  No suitable version of required package pkg://omnios/network/openssh at 7.1.1,5.11-0.151016:20151102T190704Z found:

    Reject:  pkg://omnios/network/openssh at 7.1.1,5.11-0.151016:20151102T190704Z

    Reason:  Package contains 'exclude' dependency pkg:/network/ssh on installed package

  No suitable version of required package pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z found:

    Reject:  pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z

    Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh on installed package





This is a remote server , without remote management, so removing openssh manually seems like removing all my access.

Any tips?



Thanks,



Floris





...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151104/7921bc0b/attachment.html>

From mir at miras.org  Wed Nov  4 20:21:40 2015
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 4 Nov 2015 21:21:40 +0100
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104200713.GC3405@bender.unx.cpp.edu>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<20151104200713.GC3405@bender.unx.cpp.edu>
Message-ID: <20151104212140.11c081ab@sleipner.datanom.net>

On Wed, 04 Nov 2015 12:07:14 -0800
"Paul B. Henson" <henson at acm.org> wrote:

> 
> Although it seems we'd both be happy if Dan ditched archaic sendmail and
> bundled postfix ;)...
> 
Has opensmptd ever been considered?
https://www.opensmtpd.org/

-- 
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:
Many pages make a thick book.
-------------- 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/20151104/63232134/attachment.bin>

From henson at acm.org  Wed Nov  4 20:29:33 2015
From: henson at acm.org (Paul B. Henson)
Date: Wed, 04 Nov 2015 12:29:33 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
Message-ID: <20151104202932.GD3405@bender.unx.cpp.edu>

On Wed, Nov 04, 2015 at 07:56:15AM -0500, Dan McDonald wrote:
> Does the *presence* of sendmail in a default install actually prevent
> folks from using their preferred MTAs with the mediator (which still
> works from what I can tell)?

I haven't had a chance to try out 016; I think other than being
unnecessary bloat and requiring actions to be taken to disable it
sendmail won't get in the way of another MTA.
 
> If indeed this is just about the sendmail bits being present, I have
> to say they stay, because we need an MTA out of the box, even a weak
> one, because of cron, nightly, and other bits.

It seems 014 managed to get by just fine all this time without an MTA
being installed by default, what changed? cron maybe, but nightly? How
many omnios boxes deployed do you think are compiling illumos? And of
those that are, how many are doing it without having been explicitly
configured to do so, including installing necessary additional packages?

Are you going to enable DHCP by default too now, so a box is magically
on the network after an install without needing to be configured? Maybe
set a default root password and enable sshd so a user doesn't need to
use the console to get on the box after the install before using it?
Where is the line drawn that separates "OS is installed" and "OS is
configured and ready to use"? I say the MTA falls on the far side of
that line. What is the default sendmail config, anyway? Does it try to
send directly to the Internet? How many environments allow that
nowadays? Wouldn't an admin most likely have to go configure a relayhost
before it would work? So much of out of the box... 

> If this blocks folks from configuring their systems, then I'm more
> willing to address this somehow.  IF (big IF) I end up re-yanking
> sendmail (undoing omnios-build issue #69), I will end up placing it in
> illumos-tools.

I don't think building illumos *requires* specifically sendmail? If a
user already has another MTA installed and working, what's the benefit
of forcing an unnecessary one to be installed as well? I recall being
rather annoyed when I set up my 014 build zone that the dev packages
pulled in sendmail when I already had postfix working fine.

Anyway, I think it's been made clear what my position is :)...


From henson at acm.org  Wed Nov  4 20:41:46 2015
From: henson at acm.org (Paul B. Henson)
Date: Wed, 04 Nov 2015 12:41:46 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104212140.11c081ab@sleipner.datanom.net>
References: <20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<20151104200713.GC3405@bender.unx.cpp.edu>
	<20151104212140.11c081ab@sleipner.datanom.net>
Message-ID: <20151104204145.GF3405@bender.unx.cpp.edu>

On Wed, Nov 04, 2015 at 09:21:40PM +0100, Michael Rasmussen wrote:

> Has opensmptd ever been considered?
> https://www.opensmtpd.org/

I run that on an openbsd box and it works ok. I think postfix is more
mature and usable at this point though. I'd have less objection to an
unused instance of opensmtpd sitting around than of sendmail; sendmail
and I have history :). But my preference, regardless of which MTA(s)
might be in the base OS repo, would be for none of them to be a required
component of a base install.


From info at houseofancients.nl  Wed Nov  4 20:46:06 2015
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Wed, 4 Nov 2015 20:46:06 +0000
Subject: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7
References: <mailman.1557.1446661329.63303.omnios-discuss@lists.omniti.com> 
Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC9056A30@vEX01.mindstorm-internet.local>

Hi All,

Already found the issue.

Mbuffer, provided by ms.omniti.com<http://ms.omniti.com> was the culprit.
Removed it,and it's going :)

Van: Floris van Essen ..:: House of Ancients Amstafs ::..
Verzonden: woensdag 4 november 2015 21:20
Aan: omnios-discuss at lists.omniti.com
Onderwerp: RE: OmniOS-discuss Digest, Vol 44, Issue 7


Hi All,



While trying to update 151014 to 151016.



Creating Plan (Running solver): /

pkg update: No solution was found to satisfy constraints

Plan Creation: Package solver has not found a solution to update to latest available versions.

This may indicate an overly constrained set of packages are installed.



latest incorporations:



  pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20151102T183750Z

  pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z

  pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20151102T185924Z

  pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z



The following indicates why the system cannot update to the latest version:



  No suitable version of required package pkg://omnios/network/openssh at 7.1.1,5.11-0.151016:20151102T190704Z found:

    Reject:  pkg://omnios/network/openssh at 7.1.1,5.11-0.151016:20151102T190704Z

    Reason:  Package contains 'exclude' dependency pkg:/network/ssh on installed package

  No suitable version of required package pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z found:

    Reject:  pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z

    Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh on installed package





This is a remote server , without remote management, so removing openssh manually seems like removing all my access.

Any tips?



Thanks,



Floris





...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151104/c5e62fda/attachment-0001.html>

From bfriesen at simple.dallas.tx.us  Wed Nov  4 21:55:30 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 4 Nov 2015 15:55:30 -0600 (CST)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <563A4CCC.4030200@genashor.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>
	<563A4CCC.4030200@genashor.com>
Message-ID: <alpine.GSO.2.01.1511041553400.15929@freddy.simplesystems.org>

On Wed, 4 Nov 2015, Gary Gendel wrote:

> Jacob,
> 
> I suggest getting it from pkgsrc https://pkgsrc.joyent.com/install-on-illumos/

How well do pkgsrc packages weather the upgrade storm?

I have already learned that pkgsrc binary packages may require updated 
Illumos versions in order to run and so updating from pkgsrc without 
updating OmniOS to a new enough version results in programs which 
don't run.

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 Nov  4 22:21:13 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 4 Nov 2015 16:21:13 -0600 (CST)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151104202932.GD3405@bender.unx.cpp.edu>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<20151104202932.GD3405@bender.unx.cpp.edu>
Message-ID: <alpine.GSO.2.01.1511041616590.15929@freddy.simplesystems.org>

On Wed, 4 Nov 2015, Paul B. Henson wrote:

> On Wed, Nov 04, 2015 at 07:56:15AM -0500, Dan McDonald wrote:
>> Does the *presence* of sendmail in a default install actually prevent
>> folks from using their preferred MTAs with the mediator (which still
>> works from what I can tell)?
>
> I haven't had a chance to try out 016; I think other than being
> unnecessary bloat and requiring actions to be taken to disable it
> sendmail won't get in the way of another MTA.

I think that Paul would not be very happy if he did not have a Milter 
library.  The Milter library is popular with postfix users becauses it 
supports filtering inbound mail prior to delivery (e.g. for 
greylisting).  Currently libmilter seems to be supplied by the 
sendmail package.

It would be useful if the milter library was broken out from the 
sendmail package.  It would also be useful if there was 64-bit 
sendmail and 64-bit milter library because otherwise there can be 
problems with hitting the 256 file descriptor limit under heavy email 
conditions.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From omnios at citrus-it.net  Wed Nov  4 22:44:50 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 4 Nov 2015 22:44:50 +0000 (UTC)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
Message-ID: <alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>

On Wed, 4 Nov 2015, Dan McDonald wrote:

; Does the *presence* of sendmail in a default install actually prevent folks from using their preferred MTAs with the mediator (which still works from what I can tell)?

Not directly. I install my own Sendmail package (which lives in
/opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
etc., replacing mailwrapper.

Other than a desire for a minimal system, I don't have a major problem
with some unecessary files hanging around in /usr/lib/smtp/sendmail, but
I don't want the sendmail SMF service, the files in /etc/mail/ and
particularly not /etc/init.d/sendmail which is just a wrapper to the
(wrong - for me) SMF service. I also end up with some non-mediated
Sendmail-specific stuff in /usr/bin like makemap and libmilter which
I'd rather be without.

Up until now I have uninstalled the default sendmail package and configured
my images to 'avoid' it. With this change I can no longer do either.

I don't want Sendmail to be a mandatory package but if you do decide to
leave it that way, please consider removing it from entire and changing
the dependency in mailwrapper back from optional to require instead. It
would be easier for me to create a shadow mailwrapper package than to
mess with entire - and that syncs you back up with Illumos gate too.

Would a 'group' dependency give the desired result of the package being
installed by default but still avoidable to those of us who don't want
it?

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From danmcd at omniti.com  Wed Nov  4 23:42:53 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 4 Nov 2015 18:42:53 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
Message-ID: <06949398-8649-44DA-97E4-3B0F81873626@omniti.com>


> On Nov 4, 2015, at 5:44 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> 
> Would a 'group' dependency give the desired result of the package being
> installed by default but still avoidable to those of us who don't want
> it?

That's actually an interesting idea.  I was thinking of "optional" as one possibility, but I'm noticing that type=group and type=optional appear, in practice, to be the same.  Apparently when you uninstall a group package, it's added to the image's avoid list.  For you anti-sendmail types, that may be a feature.  :)

Dan


From gary at genashor.com  Thu Nov  5 01:18:15 2015
From: gary at genashor.com (Gary Gendel)
Date: Wed, 4 Nov 2015 20:18:15 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <alpine.GSO.2.01.1511041553400.15929@freddy.simplesystems.org>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>
	<563A4CCC.4030200@genashor.com>
	<alpine.GSO.2.01.1511041553400.15929@freddy.simplesystems.org>
Message-ID: <563AAE57.1010001@genashor.com>

Bob,

So far I've been happy with pkgsrc binaries created by Joyent.  I've 
only had one issue with the qmail package and had to build it myself, 
other than that I haven't had an issue.  I've also discovered a bug in 
checkpasswd-pam where they missed a Solaris vs Linux/BSD pam difference 
and reported it.

Gary

On 11/4/2015 4:55 PM, Bob Friesenhahn wrote:
> On Wed, 4 Nov 2015, Gary Gendel wrote:
>
>> Jacob,
>>
>> I suggest getting it from pkgsrc 
>> https://pkgsrc.joyent.com/install-on-illumos/
>
> How well do pkgsrc packages weather the upgrade storm?
>
> I have already learned that pkgsrc binary packages may require updated 
> Illumos versions in order to run and so updating from pkgsrc without 
> updating OmniOS to a new enough version results in programs which 
> don't run.
>
> Bob



From jdg117 at elvis.arl.psu.edu  Thu Nov  5 03:30:54 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Wed, 04 Nov 2015 22:30:54 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: Your message of "Wed, 04 Nov 2015 19:13:42 +0100."
	<CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com> 
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<CAHG0V4fa5ecgqtVkz_GFjU6WHVNQU0w6ayHk_pjx24TptDF-hg@mail.gmail.com>
	<5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com>
	<CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw@mail.gmail.com>
Message-ID: <201511050330.tA53Usk0026833@elvis.arl.psu.edu>

In message <CAHG0V4fRjgeU6j7xPU8qm_rbOyp8TeKZz__pzFOEfCFYC7=aMw at mail.gmail.com>
, Jacob Vosmaer writes:
>go through. Now I just have to figure out how to install Ruby for myself.

# pkg install developer/gcc51

$ env PATH=/opt/apache2/ruby-2.2.3/bin:/usr/gnu/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/gcc-5.1/bin:/usr/gnu/i386-pc-solaris2.11/bin:/usr/sfw/bin \
./configure '--prefix=/opt/apache2/ruby-2.2.3' '--enable-shared' \
'--disable-install-doc' '--disable-install-rdoc' \
'CC=gcc -m64' 'CFLAGS=-m64 -O3' 'LDFLAGS=-m64' \
'CXX=g++ -m64' 'CXXFLAGS=-m64 -O3'"

John
groenveld at acm.org


From lotheac at iki.fi  Thu Nov  5 09:26:09 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Thu, 5 Nov 2015 11:26:09 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
References: <20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
Message-ID: <20151105092609.GG24984@gutsman.lotheac.fi>

On Wed, Nov 04 2015 22:44:50 +0000, Andy Fiddaman wrote:
> Would a 'group' dependency give the desired result of the package being
> installed by default but still avoidable to those of us who don't want
> it?

Good idea. I made a PR for this in omnios-build.

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From al.slater at scluk.com  Thu Nov  5 11:38:30 2015
From: al.slater at scluk.com (Al Slater)
Date: Thu, 05 Nov 2015 11:38:30 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
Message-ID: <563B3FB6.50000@scluk.com>

To the mailing list as well...

On 22/10/2015 09:43, Al Slater wrote:
 > On 21/10/2015 17:35, Dan McDonald wrote:
 >>
 >>> On Oct 21, 2015, at 6:08 AM, Al Slater <al.slater at scluk.com>
 >>> wrote:
 >>>
 >>> Hi,
 >>>
 >>> I am running omnios r151014 on a couple of machines with a couple
 >>> of zones each.  1 zone runs apache as an SSL reverse proxy, the
 >>> other runs ILB for load balancing web to app tier connections.
 >>>
 >>> I noticed that in the ILB zone, the ilbd process memory grows to
 >>> about 2Gb.   Restarting ILB releases the memory, and then the
 >>> memory usage gradually increases again, with each memory increase
 >>> approximately 2 * the size of the previous one.  I run a cronjob
 >>> twice a day ( 8am and 8pm) which restarts the ilb service and
 >>> releases the memory.
 >>>
 >>> A graph of memory usage is available at
 >>> https://www.dropbox.com/s/zaz51apxslnivlq/ILB_Memory_2_days.png?dl=0
 >>>
 >   >> There are currently 62 rules in the load balancer, with a
 >   >> total
 >>> of 664 server/port pairs.
 >>>
 >>> Is there anything I can provide that would help track this down?
 >>
 >> You can use svccfg(1M) to enable user-level memory debugging on ilb.
 >>   It may cause the ilb daemon to dump core.  (And you're just noticing
 >>   this in the process, not kernel memory consumption, correct?)
 >
 > I am seeing kernel memory consumption increasing as well, but that may
 > be a different issue.  The ilbd process memory is definitely growing.
 >
 >> As root:
 >>
 >> svcadm disable -t ilb svccfg -s ilb setenv LD_PRELOAD libumem.so
 >> svccfg -s ilb setenv UMEM_DEBUG default svccfg -s ilb refresh svcadm
 >>   enable ilb
 >>
 >> That should enable user-level memory debugging.  If you get a
 >> coredump, save it and share it.  If you don't and the ilb daemon
 >> keeps running, eventually please:
 >>
 >> gcore `pgrep ilbd`
 >>
 >> and share THAT corefile.  You can also do this by youself:
 >>
 >> mdb <ilbd-core> > ::findleaks
 >>
 >> and share ::findleaks.
 >>
 >> Once you're done generating corefiles, repeat the steps above, but
 >> use "unsetenv LD_PRELOAD" and "unsetenv UMEM_DEBUG" instead of the
 >> setenv lines.
 >
 > Thanks Dan.  As we are talking about production boxes here, I will have
 > to try and reproduce on another box and then I will give the process
 > above a go and see what we come up with.

I have reproduced the problem on a test box.

prstat shows:

3041 daemon   3946M 3946M sleep   59    0   0:48:03 0.1% ilbd/1


memstat:

root at loki:/export/home/BRIGHTON/aslate# echo ::memstat | mdb -k
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     238420               931   12%
ZFS File Data              630861              2464   31%
Anon                      1054835              4120   51%
Exec and libs                2204                 8    0%
Page cache                  10624                41    1%
Free (cachelist)             9236                36    0%
Free (freelist)            105626               412    5%

Total                     2051806              8014
Physical                  2051805              8014

mdb findleaks:

root at loki:/export/home/BRIGHTON/aslate# mdb core.3041
Loading modules: [ libumem.so.1 libc.so.1 libcmdutils.so.1 libuutil.so.1
ld.so.1 ]
  > ::findleaks
findleaks: no memory leaks detected
  >

Now, I am seeing lots of log messages like the following in
/var/adm/messages

Nov  5 11:17:01 l1-lb2 ilbd[3041]: [ID 410242 daemon.error]
ilbd_hc_probe_timer: cannot restart timer: rule ggp server _ggp.11,
disabling it


So, I was wrong about growing to 2Gb, the truth is nearer 4Gb.  I am
guessing that ilbd_hc_restart_timer is failing because no more memory
can be allocated.

I have the 4Gb core file.  Is there anything useful I can extract from
it to try and spot where the problem is?


-- Al Slater




From omnios at citrus-it.net  Thu Nov  5 13:18:26 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Thu, 5 Nov 2015 13:18:26 +0000 (UTC)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
Message-ID: <alpine.GSO.2.00.1511051310120.19426@erncre.pvgehf-vg.arg>


On Wed, 4 Nov 2015, Dan McDonald wrote:

;
; > On Nov 4, 2015, at 5:44 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
; >
; >
; > Would a 'group' dependency give the desired result of the package being
; > installed by default but still avoidable to those of us who don't want
; > it?
;
; That's actually an interesting idea.  I was thinking of "optional" as one possibility, but I'm noticing that type=group and type=optional appear, in practice, to be the same.  Apparently when you uninstall a group package, it's added to the image's avoid list.  For you anti-sendmail types, that may be a feature.  :)

sendmail is already an optional dependency of mailwrapper which is itself
required by SUNWcs. So if fresh installs aren't getting sendmail then
optional is not doing what you want here :(
I'm not sure if group would be any better.

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From lotheac at iki.fi  Thu Nov  5 13:30:34 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Thu, 5 Nov 2015 15:30:34 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.00.1511051310120.19426@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
	<alpine.GSO.2.00.1511051310120.19426@erncre.pvgehf-vg.arg>
Message-ID: <20151105133034.GH24984@gutsman.lotheac.fi>

On Thu, Nov 05 2015 13:18:26 +0000, Andy Fiddaman wrote:
> On Wed, 4 Nov 2015, Dan McDonald wrote:
> 
> ;
> ; > On Nov 4, 2015, at 5:44 PM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> ; >
> ; >
> ; > Would a 'group' dependency give the desired result of the package being
> ; > installed by default but still avoidable to those of us who don't want
> ; > it?
> ;
> ; That's actually an interesting idea.  I was thinking of "optional" as one possibility, but I'm noticing that type=group and type=optional appear, in practice, to be the same.  Apparently when you uninstall a group package, it's added to the image's avoid list.  For you anti-sendmail types, that may be a feature.  :)
> 
> sendmail is already an optional dependency of mailwrapper which is itself
> required by SUNWcs. So if fresh installs aren't getting sendmail then
> optional is not doing what you want here :(
> I'm not sure if group would be any better.

It is, I tested that a new empty image gets sendmail when I install
entire into it.

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From danmcd at omniti.com  Thu Nov  5 14:57:21 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 5 Nov 2015 09:57:21 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <563B3FB6.50000@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
Message-ID: <88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>


> On Nov 5, 2015, at 6:38 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> I have the 4Gb core file.  Is there anything useful I can extract from
> it to try and spot where the problem is?

Your one ::findleaks showed nothing.  Did your 4GB corefile have ::findleaks show nothing as well?

::umausers may be helpful.

Sharing the corefile would also be helpful.  I'm assuming, given you see problems at 4GB that ilbd is a 32-bit process, right?

Thanks,
Dan


From henson at acm.org  Thu Nov  5 20:25:22 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 12:25:22 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.01.1511041616590.15929@freddy.simplesystems.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<20151104202932.GD3405@bender.unx.cpp.edu>
	<alpine.GSO.2.01.1511041616590.15929@freddy.simplesystems.org>
Message-ID: <1e1101d11808$19177df0$4b4679d0$@acm.org>

> From: Bob Friesenhahn
> Sent: Wednesday, November 04, 2015 2:21 PM
> 
> I think that Paul would not be very happy if he did not have a Milter
> library.  The Milter library is popular with postfix users becauses it
> supports filtering inbound mail prior to delivery (e.g. for
> greylisting).  Currently libmilter seems to be supplied by the
> sendmail package.

Actually we don't currently use the milter library. And if we did, given
that postfix is coming from pkgsrc, not omnios, I'd probably use the one
from pkgsrc, not one bundled with omnios.



From henson at acm.org  Thu Nov  5 20:29:27 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 12:29:27 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
Message-ID: <1e1301d11808$ab08f130$011ad390$@acm.org>

> From: Andy Fiddaman
> Sent: Wednesday, November 04, 2015 2:45 PM
> 
> Not directly. I install my own Sendmail package (which lives in
> /opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
> etc., replacing mailwrapper.

Out of curiosity, as long as you are installing a replacement MTA, why stick
with Sendmail instead of one of the other more modern alternatives?

> Other than a desire for a minimal system

The desire for a minimal system doesn't get enough credit in this day and
age of people just clicking the "go" button and not caring about what's
happening under the hood <sigh>... It doesn't help that some commercial
vendors demand that you install the default "everything and three kitchen
sinks" OS option in order to support you. I remember arguing for weeks with
Oracle support trying to get them to justify why the "xscreensaver" package
was a hard dependency of the Oracle database server under Red Hat 5 8-/.



From henson at acm.org  Thu Nov  5 20:30:59 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 12:30:59 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
Message-ID: <1e1501d11808$e2456a20$a6d03e60$@acm.org>

> From: Dan McDonald
> Sent: Wednesday, November 04, 2015 3:43 PM
> 
> That's actually an interesting idea.  I was thinking of "optional" as one
> possibility, but I'm noticing that type=group and type=optional appear, in
> practice, to be the same.  Apparently when you uninstall a group package,
it's
> added to the image's avoid list.  For you anti-sendmail types, that may be
a
> feature.  :)

I'd prefer Sendmail not be installed by default, but I could live with the
ability to remove it.

Maybe we should characterize it less as "anti-sendmail", and more as
"pro-modern MTA whose configuration is not written in hieroglyphics" :).


From danmcd at omniti.com  Thu Nov  5 20:40:01 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 5 Nov 2015 15:40:01 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <1e1501d11808$e2456a20$a6d03e60$@acm.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
	<1e1501d11808$e2456a20$a6d03e60$@acm.org>
Message-ID: <E2337C6B-853B-43AB-9560-0AB1A917A6B5@omniti.com>


> On Nov 5, 2015, at 3:30 PM, Paul B. Henson <henson at acm.org> wrote:
> 
> 
> I'd prefer Sendmail not be installed by default, but I could live with the
> ability to remove it.

That's what happened.

> Maybe we should characterize it less as "anti-sendmail", and more as
> "pro-modern MTA whose configuration is not written in hieroglyphics" :).

Fair enough.

Next update of 016 (and first release of 017 bloody) will have sendmail set to dependency=group.  It'll install, but if you "pkg uninstall sendmail" just once it'll stay uninstalled throughout future updates.  (Will need to be uninstalled on your non-global zones as well.)

Dan


From henson at acm.org  Thu Nov  5 20:42:56 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 12:42:56 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <E2337C6B-853B-43AB-9560-0AB1A917A6B5@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
	<1e1501d11808$e2456a20$a6d03e60$@acm.org>
	<E2337C6B-853B-43AB-9560-0AB1A917A6B5@omniti.com>
Message-ID: <1e1e01d1180a$8d21b0b0$a7651210$@acm.org>

> From: Dan McDonald
> Sent: Thursday, November 05, 2015 12:40 PM
> 
> Next update of 016 (and first release of 017 bloody) will have sendmail
set to
> dependency=group.  It'll install, but if you "pkg uninstall sendmail" just
once
> it'll stay uninstalled throughout future updates.  (Will need to be
uninstalled
> on your non-global zones as well.)

Cool; thanks much for making everybody mostly happy :).


From bfriesen at simple.dallas.tx.us  Thu Nov  5 22:26:10 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 5 Nov 2015 16:26:10 -0600 (CST)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <1e1301d11808$ab08f130$011ad390$@acm.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
Message-ID: <alpine.GSO.2.01.1511051617480.17966@freddy.simplesystems.org>

On Thu, 5 Nov 2015, Paul B. Henson wrote:

>> From: Andy Fiddaman
>> Sent: Wednesday, November 04, 2015 2:45 PM
>>
>> Not directly. I install my own Sendmail package (which lives in
>> /opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
>> etc., replacing mailwrapper.
>
> Out of curiosity, as long as you are installing a replacement MTA, why stick
> with Sendmail instead of one of the other more modern alternatives?

Many of us have working Sendmail configurations and are not interested 
in taking the risk of breaking things to convert to a different MTA. 
At least not right away.

Sendmail is very reliable, is very efficient, and (to my knowledge) 
has not had a serious security issue since the early '90s.  It is also 
not very large and definitely does not qualify as "kitchen sink".

OmniOS + sendmail is a good solution for those moving from Solaris 
10 + sendmail.

If someone is starting from scratch, sendmail is likely not the best 
MTA to start with.

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  Thu Nov  5 22:47:56 2015
From: daleg at omniti.com (Dale Ghent)
Date: Thu, 5 Nov 2015 17:47:56 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <1e1301d11808$ab08f130$011ad390$@acm.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
Message-ID: <32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>


> On Nov 5, 2015, at 3:29 PM, Paul B. Henson <henson at acm.org> wrote:
> 
>> From: Andy Fiddaman
>> Sent: Wednesday, November 04, 2015 2:45 PM
>> 
>> Not directly. I install my own Sendmail package (which lives in
>> /opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
>> etc., replacing mailwrapper.
> 
> Out of curiosity, as long as you are installing a replacement MTA, why stick
> with Sendmail instead of one of the other more modern alternatives?

So I've been meditating on this question, and the broader, more general concept around MTAs on OmniOS.

First, let's take a look at the current lay of the land:

1) OmniOS packages and includes the sendmail source as it exists in illumos-gate (usr/src/cmd/sendmail)
    - This version of sendmail is quite old, last touched in any substantial way in 2010 by updating it to 8.14.4
    - There is at least one CVE against that version. Current Sendmail release is 8.15.2
    - There are some differences between Sun Sendmail and out-of-the-box sendmail.org Sendmail [1]
       -- Somewhere out there is an actual patch for this stuff, but I think that has been lost to the sands of time/Oracle

2) Several other in-tree components either depend on, or at least would sorely miss a functional LDA (at a minimum). These include crond, FMA, vi/vim, audit_warn(1M), rdist, mailx, and UUCP (ha!) "/usr/sbin/sendmail" is also the value defined by _PATH_SENDMAIL in <paths.h> but nothing in-tree seems to use it. Let's not forget nightly.sh's end-of-run mails and whatever else in omnios-userland that expects a working mail transport to be present.

3) It lacks at least one modern compile-time feature, possibly others as well.

In the end, we have an creeky old (5 year old) sendmail serving as the mail subsystem in illumos/omnios, that some utilities depend on for at least part of their functionality, and has its presence is baked in to at least 1 system header file. It's also not *standard* sendmail code, and its alterations are poorly understood and seemed to have been maintained by only John Beck @ Sun, which I think is the main reason why it has rotted for so long in illumos-gate as these changes make it sp00ky territory. To add insult to injury, the various aforementioned components references it in different locations - /usr/lib/sendmail, /usr/sbin/sendmail. Researching this led me to discover that the in-tree version of libsasl is also outdated, based on cryrus-sasl 2.1.15, where the latest is 2.1.25. Undoubtably, this also has some CVEs reg'd against it.

Software that people just immediately toss out the door and replace with something else, be it a self-rolled modern version of Sendmail or something else altogether such as Postfix or EXIM, is Bad. It just underscores how much of a failure it is due to its unmaintained state. Other than it providing a generic local delivery function, is there much use for it?

So what to do? Clearly the state of the current sendmail is far from desirable, but something needs to be there to satisfy the requirements of the other various utilities that want to spam one with annoying administrivia. With that, here are some options I've been able to figure:

OPTION 1a:
----------------
1) Find the Sun patches for sendmail and review them for relevancy, and integrate them into a modern sendmail (8.15.2 as of this writing) and push that updated wad into usr/src/cmd/sendmail to replace the current version.
2) Modernize the compile-time options of sendmail
3) Update any supporting cast (eg, libsasl)
4) Restructure sendmail packaging to break it up into separate parts (sendmail-server, sendmail-client, libmilter, etc or whatever's clever)

OPTION 1b:
----------------
1) As above, but dispense with the Sun patches (how or what this would affect is unknown to me, but if it's interop-related stuff with old unbundled Sun products, I'm more inclined to cut ties with it)

OPTION 2:
----------------
1) Kick in-tree sendmail to the curb, and let distros/distro users figure MTAs out for themselves
2) Improve mailwrapper(1M) to be cognizant  of /usr/bin/mail, /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills local delivery only to /var/mail functionality.
3) Or no mail delivery functionality of any kind?

OPTION 3:
----------------
1) Replace in-tree sendmail with an alternative (unscientific survey shows people seem to prefer Postfix)
2) Let users worry about any conversion process for sendmail -> postfix
3) Package it similarly to (OPTION 1a) so that it can be removed/replaced easily from a packaging perspective
4) We'll still need sendmail.org Sendmail source bits in order to deliver libmilter and milter functionality into Postfix.

Of course, some of these options go beyond just being an OmniOS thing and are more of a general illumos-gate stewardship question.

Any thoughts?

[1] https://www.sendmail.com/sm/open_source/docs/vendor_info/sun/differences.html

From henson at acm.org  Fri Nov  6 00:00:31 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 16:00:31 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <alpine.GSO.2.01.1511051617480.17966@freddy.simplesystems.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<alpine.GSO.2.01.1511051617480.17966@freddy.simplesystems.org>
Message-ID: <1e2501d11826$27722170$76566450$@acm.org>

> From: Bob Friesenhahn
> Sent: Thursday, November 05, 2015 2:26 PM
> 
> Sendmail is very reliable, is very efficient, and (to my knowledge)
> has not had a serious security issue since the early '90s.  It is also
> not very large and definitely does not qualify as "kitchen sink".

Now, now, the "kitchen sink" comment was in the overall context of people
not valuing minimal systems in general nowadays, not specifically targeted
at sendmail :).

> OmniOS + sendmail is a good solution for those moving from Solaris
> 10 + sendmail.
> 
> If someone is starting from scratch, sendmail is likely not the best
> MTA to start with.

I suppose if you're looking to drop something in as identical to what you
have as possible it would be a good fit. But for someone new to omnios or
switching to an illumos based distribution from some other operating system,
it's not really the best default IMHO.



From henson at acm.org  Fri Nov  6 00:03:57 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 05 Nov 2015 16:03:57 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
Message-ID: <1e2801d11826$a2758650$e76092f0$@acm.org>

> From: Dale Ghent
> Sent: Thursday, November 05, 2015 2:48 PM
> 
> Any thoughts?

I'd vote for option 2, with a preference for postfix as the omnios default
MTA :). Perhaps a legacy compatible Sendmail package could also be
available, similar to the way omnios now defaults to openssh but still
allows the legacy sunssh to be installed/used instead if necessary. But I'd
also still say there should be the option to not install any MTA at all, if
one is simply unnecessary or if there is a preference to install a
third-party one instead.

Thanks.


From lotheac at iki.fi  Fri Nov  6 06:15:58 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Fri, 6 Nov 2015 08:15:58 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
References: <alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
Message-ID: <20151106061558.GA5175@gutsman.lotheac.fi>

On Thu, Nov 05 2015 17:47:56 -0500, Dale Ghent wrote:
> 2) Several other in-tree components either depend on, or at least would sorely miss a functional LDA (at a minimum). These include crond, FMA, vi/vim, audit_warn(1M), rdist, mailx, and UUCP (ha!) "/usr/sbin/sendmail" is also the value defined by _PATH_SENDMAIL in <paths.h> but nothing in-tree seems to use it. Let's not forget nightly.sh's end-of-run mails and whatever else in omnios-userland that expects a working mail transport to be present.

I already said as much on github, but these are why I think OmniOS does
need an MSA+LDA at least.

> OPTION 2:
> ----------------
> 1) Kick in-tree sendmail to the curb, and let distros/distro users figure MTAs out for themselves
> 2) Improve mailwrapper(1M) to be cognizant  of /usr/bin/mail, /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills local delivery only to /var/mail functionality.
> 3) Or no mail delivery functionality of any kind?

What happens to the consumers listed above if this happens?

> OPTION 3:
> ----------------
> 1) Replace in-tree sendmail with an alternative (unscientific survey shows people seem to prefer Postfix)

I've been trying to avoid painting this particular bikeshed until it's
at least planned to be built, so I wouldn't draw any conclusions yet.

> 2) Let users worry about any conversion process for sendmail -> postfix

There's no I can see reason anyone wanting to keep using sendmail
couldn't use a different copy, so I don't consider this a problem.

> 3) Package it similarly to (OPTION 1a) so that it can be removed/replaced easily from a packaging perspective
> 4) We'll still need sendmail.org Sendmail source bits in order to deliver libmilter and milter functionality into Postfix.

Where does the milter requirement come from? Per KYSTY I would think
OmniOS should only deliver what it needs to function itself. Are there
milter consumers in -gate or omnios-userland?

If you're asking for opinions on what to do, I don't think keeping
sendmail on life support is worth it, which removes option 1. Since
there are MSA/LDA consumers, option 2 isn't feasible either. That leaves
only option 3, unless "do nothing" is an option.

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From daleg at omniti.com  Fri Nov  6 06:55:54 2015
From: daleg at omniti.com (Dale Ghent)
Date: Fri, 6 Nov 2015 01:55:54 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151106061558.GA5175@gutsman.lotheac.fi>
References: <alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
	<20151106061558.GA5175@gutsman.lotheac.fi>
Message-ID: <2DD269E6-BCC0-43D5-BB45-F4722740DCD2@omniti.com>


> On Nov 6, 2015, at 1:15 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
> 
> On Thu, Nov 05 2015 17:47:56 -0500, Dale Ghent wrote:
>> 2) Several other in-tree components either depend on, or at least would sorely miss a functional LDA (at a minimum). These include crond, FMA, vi/vim, audit_warn(1M), rdist, mailx, and UUCP (ha!) "/usr/sbin/sendmail" is also the value defined by _PATH_SENDMAIL in <paths.h> but nothing in-tree seems to use it. Let's not forget nightly.sh's end-of-run mails and whatever else in omnios-userland that expects a working mail transport to be present.
> 
> I already said as much on github, but these are why I think OmniOS does
> need an MSA+LDA at least.

I know, I was just bringing to conversation to a wider audience.

> 
>> OPTION 2:
>> ----------------
>> 1) Kick in-tree sendmail to the curb, and let distros/distro users figure MTAs out for themselves
>> 2) Improve mailwrapper(1M) to be cognizant  of /usr/bin/mail, /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills local delivery only to /var/mail functionality.
>> 3) Or no mail delivery functionality of any kind?
> 
> What happens to the consumers listed above if this happens?

Thats where mailwrapper (or some component in addition to it) comes in and provides a very basic local delivery only. Like, not even remote delivery, and the destination user must be in /etc/passwd. No-frills, but it gets a mail to some destination. It would need to be coded. Hell, it could be written in perl or python for all I care. I have no final form in my head, just a general concept.

>> OPTION 3:
>> ----------------
>> 1) Replace in-tree sendmail with an alternative (unscientific survey shows people seem to prefer Postfix)
> 
> I've been trying to avoid painting this particular bikeshed until it's
> at least planned to be built, so I wouldn't draw any conclusions yet.
> 
>> 2) Let users worry about any conversion process for sendmail -> postfix
> 
> There's no I can see reason anyone wanting to keep using sendmail
> couldn't use a different copy, so I don't consider this a problem.
> 
>> 3) Package it similarly to (OPTION 1a) so that it can be removed/replaced easily from a packaging perspective
>> 4) We'll still need sendmail.org Sendmail source bits in order to deliver libmilter and milter functionality into Postfix.
> 
> Where does the milter requirement come from? Per KYSTY I would think
> OmniOS should only deliver what it needs to function itself. Are there
> milter consumers in -gate or omnios-userland?

Well, if we bring in a sendmail replacement and we neuter its features, no one will use it or at least consider serious level of use of it; and it will end up being uninstalled and thrown out like the sendmail we currently have. This is a flaw that the current in-tree sendmail suffers from (in addition to being woefully out of date)

Which brings us back to the philosophical question - why include software that nobody wants because its most basic level of functionality is often insufficient? But if we don't include it, other things suffer or are degraded in out-of-the-box functionality. I believe in KYSTY - but to a point. In these grey areas of overlap, some exceptions or special considerations must be made. Let's be real here. There are many area in illumos that someone can point to and ask why its there if one to strictly interpret KYSTY in all cases.

> If you're asking for opinions on what to do, I don't think keeping
> sendmail on life support is worth it, which removes option 1. Since
> there are MSA/LDA consumers, option 2 isn't feasible either. That leaves
> only option 3, unless "do nothing" is an option.

Well "do nothing" has been the apparent course of action for almost 6 years now. But that's speaking in general illumos-gate terms. As far as OmniOS goes, we can completely ignore that part of the tree and install our own thing in our own way... but I want to at least explore the options which have a bearing on illumos-gate (ie; the greater illumos community) first.

/dale

From lotheac at iki.fi  Fri Nov  6 07:17:35 2015
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Fri, 6 Nov 2015 09:17:35 +0200
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <2DD269E6-BCC0-43D5-BB45-F4722740DCD2@omniti.com>
References: <alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
	<20151106061558.GA5175@gutsman.lotheac.fi>
	<2DD269E6-BCC0-43D5-BB45-F4722740DCD2@omniti.com>
Message-ID: <20151106071735.GI24984@gutsman.lotheac.fi>

On Fri, Nov 06 2015 01:55:54 -0500, Dale Ghent wrote:
> >> OPTION 2:
> >> ----------------
> >> 1) Kick in-tree sendmail to the curb, and let distros/distro users figure MTAs out for themselves
> >> 2) Improve mailwrapper(1M) to be cognizant  of /usr/bin/mail, /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills local delivery only to /var/mail functionality.
> >> 3) Or no mail delivery functionality of any kind?
> > 
> > What happens to the consumers listed above if this happens?
> 
> Thats where mailwrapper (or some component in addition to it) comes in and provides a very basic local delivery only. Like, not even remote delivery, and the destination user must be in /etc/passwd. No-frills, but it gets a mail to some destination. It would need to be coded. Hell, it could be written in perl or python for all I care. I have no final form in my head, just a general concept.

Ah, okay. I'm fine with that but it sounds like more work than dropping
in an alternative.

> >> 4) We'll still need sendmail.org Sendmail source bits in order to deliver libmilter and milter functionality into Postfix.
> > 
> > Where does the milter requirement come from? Per KYSTY I would think
> > OmniOS should only deliver what it needs to function itself. Are there
> > milter consumers in -gate or omnios-userland?
> 
> Well, if we bring in a sendmail replacement and we neuter its features, no one will use it or at least consider serious level of use of it; and it will end up being uninstalled and thrown out like the sendmail we currently have. This is a flaw that the current in-tree sendmail suffers from (in addition to being woefully out of date)

I'm not really saying we should actively neuter a replacement's features
because OmniOS itself doesn't need them, but I don't see the point of
bringing in milter either.

> Which brings us back to the philosophical question - why include software that nobody wants because its most basic level of functionality is often insufficient? But if we don't include it, other things suffer or are degraded in out-of-the-box functionality. I believe in KYSTY - but to a point. In these grey areas of overlap, some exceptions or special considerations must be made. Let's be real here. There are many area in illumos that someone can point to and ask why its there if one to strictly interpret KYSTY in all cases.

Sure, generally speaking. In this particular context I believe users
should ship their own if they want to deploy a mail server, but all
nodes should be able to deliver mail locally. It would also be great if
the default install lended itself to mail submission (eg. a satellite
mailer configuration), perhaps even with opportunistic TLS, to cover
more of the common use cases, but that might be just my personal bias
talking.

> > If you're asking for opinions on what to do, I don't think keeping
> > sendmail on life support is worth it, which removes option 1. Since
> > there are MSA/LDA consumers, option 2 isn't feasible either. That leaves
> > only option 3, unless "do nothing" is an option.
> 
> Well "do nothing" has been the apparent course of action for almost 6 years now. But that's speaking in general illumos-gate terms. As far as OmniOS goes, we can completely ignore that part of the tree and install our own thing in our own way... but I want to at least explore the options which have a bearing on illumos-gate (ie; the greater illumos community) first.

True. I do think that excising sendmail and replacing it with something
would also benefit the greater illumos community, but I'm already
dreading a potential developer list discussion on the subject :)

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From al.slater at scluk.com  Fri Nov  6 07:22:11 2015
From: al.slater at scluk.com (Al Slater)
Date: Fri, 06 Nov 2015 07:22:11 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
Message-ID: <563C5523.20506@scluk.com>

Hi Dan,

On 05/11/2015 14:57, Dan McDonald wrote:
>
>> On Nov 5, 2015, at 6:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> I have the 4Gb core file.  Is there anything useful I can extract
>> from it to try and spot where the problem is?
>
> Your one ::findleaks showed nothing.  Did your 4GB corefile have
> ::findleaks show nothing as well?
>
> ::umausers may be helpful.


root at loki:/export/home/BRIGHTON/aslate# mdb core.3041
Loading modules: [ libumem.so.1 libc.so.1 libcmdutils.so.1 libuutil.so.1
ld.so.1 ]
> ::umausers
71424 bytes for 62 allocations with data size 1152:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x18f
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libumem.so.1`calloc+0x50
          i_ilbd_alloc_sg+0x13
          ilbd_create_sg+0x9a
          ilbd_scf_instance_walk_pg+0x2a6
          ilbd_walk_sg_pgs+0x37
          i_ilbd_read_config+0x28
          main_loop+0x7f
          main+0x1d3
          _start+0x83
53120 bytes for 664 allocations with data size 80:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x18f
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libumem.so.1`calloc+0x50
          ilbd_hc_srv_add+0x18
          ilbd_hc_associate_rule+0xd8
          ilbd_create_rule+0x1a3
          ilbd_scf_instance_walk_pg+0x1c4
          ilbd_walk_rule_pgs+0x37
          i_ilbd_read_config+0x4e
          main_loop+0x7f
          main+0x1d3
          _start+0x83
53120 bytes for 664 allocations with data size 80:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x18f
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libumem.so.1`calloc+0x50
          i_add_srv2sg+0x15
          ilbd_add_server_to_group+0x310
          ilbd_scf_instance_walk_pg+0x2dd
          ilbd_walk_sg_pgs+0x37
          i_ilbd_read_config+0x28
          main_loop+0x7f
          main+0x1d3
          _start+0x83
31584 bytes for 658 allocations with data size 48:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x99
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libumem.so.1`calloc+0x50
          libinetutil.so.1`iu_schedule_timer_ms+0x2d
          libinetutil.so.1`iu_schedule_timer+0x37
          ilbd_hc_restart_timer+0xbc
          ilbd_hc_probe_timer+0x23
          libinetutil.so.1`iu_expire_timers+0xbe
          ilbd_hc_timeout+0x11
          main_loop+0xe6
          main+0x1d3
          _start+0x83
12288 bytes for 1 allocations with data size 12288:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x18f
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libc.so.1`ltzset_u+0xa2
          libc.so.1`localtime_r+0x35
          libc.so.1`ctime_r+0x2c
          libc.so.1`vsyslog+0x1e4
          ilbd_log+0x48
          main+0x15e
          _start+0x83
10368 bytes for 54 allocations with data size 192:
          libumem.so.1`umem_cache_alloc_debug+0x1fe
          libumem.so.1`umem_cache_alloc+0x99
          libumem.so.1`umem_alloc+0x50
          libumem.so.1`umem_malloc+0x36
          libumem.so.1`calloc+0x50
          i_alloc_ilbd_rule+0x17
          ilbd_create_rule+0xfa
          ilbd_scf_instance_walk_pg+0x1c4
          ilbd_walk_rule_pgs+0x37
          i_ilbd_read_config+0x4e
          main_loop+0x7f
          main+0x1d3
          _start+0x83


> Sharing the corefile would also be helpful.

I have put it on dropbox

https://www.dropbox.com/s/y6cv78d1xk5j5u7/core.3041.gz?dl=0

> I'm assuming, given you see problems at 4GB that ilbd is a 32-bit
> process, right?

Yes,

#  file /usr/lib/inet/ilbd
/usr/lib/inet/ilbd:     ELF 32-bit LSB executable 80386 Version 1,
dynamically linked, not stripped, no debugging information available

cheers

-- 
Al Slater

Technical Director
SCL

Phone : +44 (0)1273 666607
Fax   : +44 (0)1273 666601
email : al.slater at scluk.com

Stanton Consultancy Ltd

Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU

Registered in England Company number: 1957652 VAT number: GB 760 2433 55


From al.slater at scluk.com  Fri Nov  6 08:11:55 2015
From: al.slater at scluk.com (Al Slater)
Date: Fri, 06 Nov 2015 08:11:55 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
Message-ID: <563C60CB.3060208@scluk.com>

On 05/11/2015 14:57, Dan McDonald wrote:
>
>> On Nov 5, 2015, at 6:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> I have the 4Gb core file.  Is there anything useful I can extract from
>> it to try and spot where the problem is?
>
> Your one ::findleaks showed nothing.  Did your 4GB corefile have ::findleaks show nothing as well?

::findleaks against the 4GB corefile showed nothing.

-- 
Al Slater




From danmcd at omniti.com  Fri Nov  6 14:39:05 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 09:39:05 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <563C60CB.3060208@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
Message-ID: <56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>


> On Nov 6, 2015, at 3:11 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> On 05/11/2015 14:57, Dan McDonald wrote:
>> 
>>> On Nov 5, 2015, at 6:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>> 
>>> I have the 4Gb core file.  Is there anything useful I can extract from
>>> it to try and spot where the problem is?
>> 
>> Your one ::findleaks showed nothing.  Did your 4GB corefile have ::findleaks show nothing as well?
> 
> ::findleaks against the 4GB corefile showed nothing.

None of the libumem stats show anything resembling leaks or even excessive allocation.

pmap(1) of the corefile is semi-interesting:

r151014(~/corefiles/Slater)[0]% pmap core.3041 
core 'core.3041' of 3041:       /usr/lib/inet/ilbd
0802E000     104K rw---    [ stack ]
08050000      76K r-x--  /usr/lib/inet/ilbd
08073000       4K rw---  /usr/lib/inet/ilbd
08074000    1252K rw---    [ heap ]
081B0000     256K rwx--    [ anon ]
08200000    2048K rwx--    [ anon ]
08410000     256K rwx--    [ anon ]
08460000     512K rwx--    [ anon ]
084F0000    1024K rwx--    [ anon ]
08600000    8192K rwx--    [ anon ]
08E10000     256K rwx--    [ anon ]
08E60000     512K rwx--    [ anon ]
08EF0000    1024K rwx--    [ anon ]
09000000   65536K rwx--    [ anon ]
0D010000     256K rwx--    [ anon ]
0D060000     512K rwx--    [ anon ]
0D0F0000    1024K rwx--    [ anon ]
0D200000  262144K rwx--    [ anon ]
1D210000     256K rwx--    [ anon ]
1D260000     512K rwx--    [ anon ]
1D2F0000    1024K rwx--    [ anon ]
1D400000  524288K rwx--    [ anon ]
3D410000     256K rwx--    [ anon ]
3D460000     512K rwx--    [ anon ]
3D4F0000    1024K rwx--    [ anon ]
3D600000 1048576K rwx--    [ anon ]
7D610000     256K rwx--    [ anon ]
7D660000     512K rwx--    [ anon ]
7D6F0000    1024K rwx--    [ anon ]
7D800000 1048576K rwx--    [ anon ]
BD810000     256K rwx--    [ anon ]
BD860000     512K rwx--    [ anon ]
BD8F0000    1024K rwx--    [ anon ]
BDA00000  524288K rwx--    [ anon ]
DDA10000     256K rwx--    [ anon ]
DDA60000     512K rwx--    [ anon ]
DDAF0000    1024K rwx--    [ anon ]
DDC00000  262144K rwx--    [ anon ]
EDC10000     256K rwx--    [ anon ]
EDC60000     512K rwx--    [ anon ]
EDCF0000    1024K rwx--    [ anon ]
EDE00000  131072K rwx--    [ anon ]
F5E10000     256K rwx--    [ anon ]
F5E60000     512K rwx--    [ anon ]
F5EF0000    1024K rwx--    [ anon ]
F6000000   65536K rwx--    [ anon ]
FA010000     256K rwx--    [ anon ]
FA060000     512K rwx--    [ anon ]
FA0F0000    1024K rwx--    [ anon ]
FA200000   32768K rwx--    [ anon ]
FC210000     256K rwx--    [ anon ]
FC260000     512K rwx--    [ anon ]
FC2F0000    1024K rwx--    [ anon ]
FC400000   16384K rwx--    [ anon ]
FD410000     256K rwx--    [ anon ]
FD460000     512K rwx--    [ anon ]
FD4F0000    1024K rwx--    [ anon ]
FD600000    8192K rwx--    [ anon ]
FDE10000     256K rwx--    [ anon ]
FDE60000     512K rwx--    [ anon ]
FDEF0000    1024K rwx--    [ anon ]
FE000000    4096K rwx--    [ anon ]
FE410000     256K rwx--    [ anon ]
FE460000     512K rwx--    [ anon ]
FE4F0000    1024K rwx--    [ anon ]
FE600000    2048K rwx--    [ anon ]
FE820000    1024K rwx--    [ anon ]
FE930000    1024K rwx--    [ anon ]
FEA40000     512K rwx--    [ anon ]
FEAD0000     256K rwx--    [ anon ]
FEB20000     128K rwx--    [ anon ]
FEB50000      64K rwx--    [ anon ]
FEB70000      64K rwx--    [ anon ]
FEB90000       4K rwx--    [ anon ]
FEBA0000      20K r-x--  /usr/lib/libilb.so.1
FEBB5000       4K rw---  /usr/lib/libilb.so.1
FEBC0000      32K r-x--  /lib/libuutil.so.1
FEBD8000       4K rw---  /lib/libuutil.so.1
FEBE0000       4K rwx--    [ anon ]
FEBF0000     172K r-x--  /lib/libscf.so.1
FEC2B000       4K rw---  /lib/libscf.so.1
FEC30000      20K r-x--  /lib/libinetutil.so.1
FEC45000       4K rw---  /lib/libinetutil.so.1
FEC50000       4K rwx--    [ anon ]
FEC60000      20K r-x--  /lib/libcmdutils.so.1
FEC75000       4K rw---  /lib/libcmdutils.so.1
FEC80000       4K r----*   [ anon ]
FEC90000      64K rwx--    [ anon ]
FECB0000      64K rwx--    [ anon ]
FECD0000     416K r-x--  /lib/libnsl.so.1
FED48000       8K rw---  /lib/libnsl.so.1
FED4A000      20K rw---  /lib/libnsl.so.1
FED50000       4K rwx--    [ anon ]
FED60000      52K r-x--  /lib/libsocket.so.1
FED7D000       4K rw---  /lib/libsocket.so.1
FED80000      24K rwx--    [ anon ]
FED90000    1252K r-x--  /lib/libc.so.1
FEED9000      36K rwx--  /lib/libc.so.1
FEEE2000       8K rwx--  /lib/libc.so.1
FEEF0000       4K rwx--    [ anon ]
FEF00000     196K r-x--  /lib/libumem.so.1
FEF40000       8K rwx--  /lib/libumem.so.1
FEF52000      76K rw---  /lib/libumem.so.1
FEF65000      24K rw---  /lib/libumem.so.1
FEF70000       4K r----*   [ anon ]
FEF80000       4K rwx--    [ anon ]
FEF90000       4K rw---    [ anon ]
FEFA0000       4K rw---    [ anon ]
FEFB0000       4K rwx--    [ anon ]
FEFB5000     216K r-x--  /lib/ld.so.1
FEFFB000       8K rwx--  /lib/ld.so.1
FEFFD000       4K rwx--  /lib/ld.so.1
 total   4040340K
r151014(~/corefiles/Slater)[0]% 

Lots of LARGE anonymous mappings.  I wonder why that happened? I'll dig into that a bit more.

Dan


From danmcd at omniti.com  Fri Nov  6 14:51:23 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 09:51:23 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
Message-ID: <5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>


> On Nov 6, 2015, at 9:39 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> Lots of LARGE anonymous mappings.  I wonder why that happened? I'll dig into that a bit more.

pmap(1) works even better on running processes.  Could you run, say "pmap -xa `pgrep ilbd`" on your running machine?

Dan


From al.slater at scluk.com  Fri Nov  6 15:38:38 2015
From: al.slater at scluk.com (Al Slater)
Date: Fri, 6 Nov 2015 15:38:38 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
Message-ID: <563CC97E.9010108@scluk.com>

On 06/11/15 14:51, Dan McDonald wrote:
> 
>> On Nov 6, 2015, at 9:39 AM, Dan McDonald <danmcd at omniti.com> wrote:
>>
>> Lots of LARGE anonymous mappings.  I wonder why that happened? I'll dig into that a bit more.
> 
> pmap(1) works even better on running processes.  Could you run, say "pmap -xa `pgrep ilbd`" on your running machine?

Here you go...

root at loki:/export/home/BRIGHTON/aslate# pmap -xa `pgrep ilbd`
12346:  /usr/lib/inet/ilbd
 Address  Kbytes     RSS    Anon  Locked Mode   Mapped File
08027000     132     132     132       - rw---    [ stack ]
08050000      76      76       -       - r-x--  ilbd
08073000       4       4       4       - rw---  ilbd
08074000      96       -       -       - rw---  ilbd
0808C000    1156    1140    1112       - rw---    [ heap ]
0D200000  262144  262144  262144       - rwx--    [ anon ]
1D400000  524288  524288  524288       - rwx--    [ anon ]
3D600000 1048576 1048576 1048576       - rwx--    [ anon ]
7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
BDA00000  524288  524288  524288       - rwx--    [ anon ]
DDC00000  262144  262144  262144       - rwx--    [ anon ]
EDE00000  131072  131072  131072       - rwx--    [ anon ]
F6000000   65536   65536   65536       - rwx--    [ anon ]
FA200000   32768   32768   32768       - rwx--    [ anon ]
FC400000   16384   16384   16384       - rwx--    [ anon ]
FD600000    8192    8192    8192       - rwx--    [ anon ]
FE000000    4096    4096    4096       - rwx--    [ anon ]
FE600000    2048    2048    2048       - rwx--    [ anon ]
FE8A0000      36      16       -       - r-x--  libtsol.so.2
FE8B9000       4       4       4       - rw---  libtsol.so.2
FE8C0000       4       4       4       - rwx--    [ anon ]
FE8D0000     140     112       -       - r-x--  libbsm.so.1
FE903000      28      28      28       - rw---  libbsm.so.1
FE90A000       4       -       -       - rw---  libbsm.so.1
FE910000      16      16       -       - r-x--  libsecdb.so.1
FE924000       4       4       4       - rw---  libsecdb.so.1
FE930000    1024    1024    1024       - rwx--    [ anon ]
FEA40000     512     512     512       - rwx--    [ anon ]
FEAD0000     256     256     256       - rwx--    [ anon ]
FEB20000     128     128     128       - rwx--    [ anon ]
FEB50000      64      64      64       - rwx--    [ anon ]
FEB70000      64      16      16       - rwx--    [ anon ]
FEB90000       4       4       4       - rwx--    [ anon ]
FEBA0000      20      20       -       - r-x--  libilb.so.1
FEBB5000       4       4       4       - rw---  libilb.so.1
FEBC0000      32      32       -       - r-x--  libuutil.so.1
FEBD8000       4       4       4       - rw---  libuutil.so.1
FEBE0000       4       4       4       - rwx--    [ anon ]
FEBF0000     172     148       -       - r-x--  libscf.so.1
FEC2B000       4       4       4       - rw---  libscf.so.1
FEC30000      20      20       -       - r-x--  libinetutil.so.1
FEC45000       4       4       4       - rw---  libinetutil.so.1
FEC50000       4       4       4       - rwx--    [ anon ]
FEC60000      20      12       -       - r-x--  libcmdutils.so.1
FEC75000       4       4       4       - rw---  libcmdutils.so.1
FEC80000       4       4       -       - r--s-  dev:528,24 ino:2821218250
FEC90000      64      64       4       - rwx--    [ anon ]
FECB0000      64      64       4       - rwx--    [ anon ]
FECD0000     416     368       -       - r-x--  libnsl.so.1
FED48000       8       8       8       - rw---  libnsl.so.1
FED4A000      20      16       4       - rw---  libnsl.so.1
FED50000       4       4       4       - rwx--    [ anon ]
FED60000      52      48       -       - r-x--  libsocket.so.1
FED7D000       4       4       4       - rw---  libsocket.so.1
FED80000      24      12      12       - rwx--    [ anon ]
FED90000    1252     936       -       - r-x--  libc_hwcap1.so.1
FEED9000      36      36      32       - rwx--  libc_hwcap1.so.1
FEEE2000       8       8       8       - rwx--  libc_hwcap1.so.1
FEEF0000       4       4       4       - rwx--    [ anon ]
FEF00000     196     112       -       - r-x--  libumem.so.1
FEF40000       8       4       4       - rwx--  libumem.so.1
FEF52000      76      72      16       - rw---  libumem.so.1
FEF65000      24      24      24       - rw---  libumem.so.1
FEF70000       4       4       -       - r--s-  ld.config
FEF80000       4       4       4       - rwx--    [ anon ]
FEF90000       4       4       4       - rw---    [ anon ]
FEFA0000       4       4       4       - rw---    [ anon ]
FEFB0000       4       4       4       - rwx--    [ anon ]
FEFB5000     216     216       -       - r-x--  ld.so.1
FEFFB000       8       8       8       - rwx--  ld.so.1
FEFFD000       4       4       4       - rwx--  ld.so.1
-------- ------- ------- ------- -------
total Kb 3936668 3935948 3933588

-- 
Al Slater


From danmcd at omniti.com  Fri Nov  6 15:43:35 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 10:43:35 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <563CC97E.9010108@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
Message-ID: <0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>


> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> 3D600000 1048576 1048576 1048576       - rwx--    [ anon ]
> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]

Hmmm.

I wonder if those are pre-allocated by libumem?  They're HUGE (1G) and more around them are smaller

Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?

Thanks,
Dan


From al.slater at scluk.com  Fri Nov  6 15:57:08 2015
From: al.slater at scluk.com (Al Slater)
Date: Fri, 6 Nov 2015 15:57:08 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
Message-ID: <563CCDD4.7040903@scluk.com>

On 06/11/15 15:43, Dan McDonald wrote:
> 
>> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> 3D600000 1048576 1048576 1048576       - rwx--    [ anon ]
>> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
> 
> Hmmm.
> 
> I wonder if those are pre-allocated by libumem?  They're HUGE (1G) and more around them are smaller
> 
> Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?

No problem Dan, this is from a production ilbd that was restarted at
07:00 GMT

14585:  /usr/lib/inet/ilbd
 Address  Kbytes     RSS    Anon  Locked Mode   Mapped File
0802D000     108     108     108       - rw---    [ stack ]
08050000      76      76       -       - r-x--  ilbd
08073000       4       4       4       - rw---  ilbd
08074000      96       -       -       - rw---  ilbd
0808C000     252     248     244       - rw---    [ heap ]
7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
BDA00000  524288  524288  524288       - rwx--    [ anon ]
DDC00000  262144  262144  262144       - rwx--    [ anon ]
EDE00000  131072  131072  131072       - rwx--    [ anon ]
F6000000   65536   65536   65536       - rwx--    [ anon ]
FA200000   32768   32768   32768       - rwx--    [ anon ]
FC400000   16384   16384   16384       - rwx--    [ anon ]
FD600000    8192    8192    8192       - rwx--    [ anon ]
FE000000    4096    4096    4096       - rwx--    [ anon ]
FE600000    2048    2048    2048       - rwx--    [ anon ]
FE9A0000    1024    1024    1024       - rwx--    [ anon ]
FEAB0000     512     512     512       - rwx--    [ anon ]
FEB40000     256     256     256       - rwx--    [ anon ]
FEB90000     128     128     128       - rwx--    [ anon ]
FEBC0000      64      64      64       - rwx--    [ anon ]
FEBE0000      64      16      16       - rwx--    [ anon ]
FEC00000       4       4       4       - rwx--    [ anon ]
FEC10000      20      20       -       - r-x--  libilb.so.1
FEC25000       4       4       4       - rw---  libilb.so.1
FEC30000      32      32       -       - r-x--  libuutil.so.1
FEC48000       4       4       4       - rw---  libuutil.so.1
FEC50000       4       4       4       - rwx--    [ anon ]
FEC60000     172     172       -       - r-x--  libscf.so.1
FEC9B000       4       4       4       - rw---  libscf.so.1
FECA0000      20      20       -       - r-x--  libinetutil.so.1
FECB5000       4       4       4       - rw---  libinetutil.so.1
FECC0000       4       4       4       - rwx--    [ anon ]
FECD0000      20      20       -       - r-x--  libcmdutils.so.1
FECE5000       4       4       4       - rw---  libcmdutils.so.1
FECF0000       4       4       -       - r--s-  dev:528,9 ino:1532084444
FED00000      64      64       4       - rwx--    [ anon ]
FED20000      64      64       4       - rwx--    [ anon ]
FED40000     416     388       -       - r-x--  libnsl.so.1
FEDB8000       8       8       8       - rw---  libnsl.so.1
FEDBA000      20      12       -       - rw---  libnsl.so.1
FEDC0000       4       4       4       - rwx--    [ anon ]
FEDD0000      52      52       -       - r-x--  libsocket.so.1
FEDED000       4       4       4       - rw---  libsocket.so.1
FEDF0000      24      12      12       - rwx--    [ anon ]
FEE00000       4       4       4       - rwx--    [ anon ]
FEE10000    1252     888       -       - r-x--  libc_hwcap1.so.1
FEF59000      36      36      32       - rwx--  libc_hwcap1.so.1
FEF62000       8       8       8       - rwx--  libc_hwcap1.so.1
FEF70000       4       4       -       - r--s-  ld.config
FEF80000       4       4       4       - rwx--    [ anon ]
FEF90000       4       4       4       - rw---    [ anon ]
FEFA0000       4       4       4       - rw---    [ anon ]
FEFB0000       4       4       4       - rwx--    [ anon ]
FEFB5000     216     216       -       - r-x--  ld.so.1
FEFFB000       8       8       8       - rwx--  ld.so.1
FEFFD000       4       4       4       - rwx--  ld.so.1
-------- ------- ------- ------- -------
total Kb 2100192 2099632 2097600       -

Definitely no libumem:
root at thor:/export/home/BRIGHTON/aslate# pldd 14585
14585:  /usr/lib/inet/ilbd
/zones/roots/l1-lb1/root/usr/lib/libc/libc_hwcap1.so.1
/zones/roots/l1-lb1/root/lib/libsocket.so.1
/zones/roots/l1-lb1/root/lib/libnsl.so.1
/zones/roots/l1-lb1/root/lib/libcmdutils.so.1
/zones/roots/l1-lb1/root/lib/libinetutil.so.1
/zones/roots/l1-lb1/root/lib/libscf.so.1
/zones/roots/l1-lb1/root/lib/libuutil.so.1
/zones/roots/l1-lb1/root/usr/lib/libilb.so.1


-- 
Al Slater


From danmcd at omniti.com  Fri Nov  6 16:25:09 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 11:25:09 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <563CCDD4.7040903@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
Message-ID: <C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>


> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> 
> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
> BDA00000  524288  524288  524288       - rwx--    [ anon ]
> DDC00000  262144  262144  262144       - rwx--    [ anon ]
> EDE00000  131072  131072  131072       - rwx--    [ anon ]

More huge anonymous mappings (1G, 512MB, 256MB, 128MB).

I don't know pmap as well as I should.  I don't see anything in the man page to give me further insight into why these chunks of memory are being eaten.

Dan


From danmcd at omniti.com  Fri Nov  6 18:31:19 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 13:31:19 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
Message-ID: <964395C2-376C-48A1-BFE8-A655EB667992@omniti.com>


> On Nov 6, 2015, at 11:25 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
>> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
>> 
>> 
>> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
>> BDA00000  524288  524288  524288       - rwx--    [ anon ]
>> DDC00000  262144  262144  262144       - rwx--    [ anon ]
>> EDE00000  131072  131072  131072       - rwx--    [ anon ]
> 
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
> 

You said you had a test box, right?

Can you:

- Disable UMEM_DEBUG
- RESTART the service.
- IMMEDIATELY after restart do pmap, and do pmap once per (sec, 10 sec, something) to see how it grows?

After that, maybe we can dtrace and see what's going on.

Dan


From bfriesen at simple.dallas.tx.us  Fri Nov  6 18:33:47 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 6 Nov 2015 12:33:47 -0600 (CST)
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
Message-ID: <alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>

On Fri, 6 Nov 2015, Dan McDonald wrote:
>
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
>
> I don't know pmap as well as I should.  I don't see anything in the 
> man page to give me further insight into why these chunks of memory 
> are being eaten.

It is pretty common for memory allocators to use anonymous mappings 
for large memory allocations.  This allows releasing memory back to 
the system.

Some applications use algorithms where they double the memory size 
request from the previous request when a little more memory is 
required in order to lessen the hit from many realloc() calls.  This 
might explain the power-of two sizes.  If this is being done, the 
smaller power of two allocations may be a bug.

Tracing mmap() calls on the program while is is running might reveal 
something.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From alka at hfg-gmuend.de  Fri Nov  6 21:11:42 2015
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Fri, 6 Nov 2015 22:11:42 +0100
Subject: [OmniOS-discuss] SMB 2.1 any many other improvements
In-Reply-To: <alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
Message-ID: <563D178E.8090401@hfg-gmuend.de>

Just saw the notice at Illumos IRC

Long awaited (Gordon Ross from Nexenta, gratulation, among others)
SMB 2.1 is there - my Mac users will be happy

https://www.illumos.org/issues/6399
https://www.illumos.org/issues/6398
https://www.illumos.org/issues/6352
https://www.illumos.org/issues/6400
https://www.illumos.org/issues/1087

soon
https://www.illumos.org/issues/3525

Pretty good news for OmniOS


Two question
- When -  will SMB 2.1 be included - to LTS or 151016??
- Can 6352 support Primary and a Secondary AD Server as a failover - and how

Gea

From henson at acm.org  Fri Nov  6 22:59:29 2015
From: henson at acm.org (Paul B. Henson)
Date: Fri, 06 Nov 2015 14:59:29 -0800
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <2DD269E6-BCC0-43D5-BB45-F4722740DCD2@omniti.com>
References: <alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
	<32A80A25-4BE4-4C88-90DC-305A0BD07348@omniti.com>
	<20151106061558.GA5175@gutsman.lotheac.fi>
	<2DD269E6-BCC0-43D5-BB45-F4722740DCD2@omniti.com>
Message-ID: <005401d118e6$cb7a9c50$626fd4f0$@acm.org>

> Dale Ghent
> Sent: Thursday, November 05, 2015 10:56 PM
>
> Well "do nothing" has been the apparent course of action for almost 6
years
> now. But that's speaking in general illumos-gate terms. As far as OmniOS
> goes, we can completely ignore that part of the tree and install our own
thing
> in our own way... but I want to at least explore the options which have a
> bearing on illumos-gate (ie; the greater illumos community) first.

>From a design perspective, I think the best option would be to rip sendmail
out of illumos-gate and replace it with something that just did simple local
mail delivery so the components of illumos-gate that require mail aren't
broken. Then distributions could add their own MTA of choice and/or allow
end-users to install other ones.


From danmcd at omniti.com  Fri Nov  6 23:06:19 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 6 Nov 2015 18:06:19 -0500
Subject: [OmniOS-discuss] SMB 2.1 any many other improvements
In-Reply-To: <563D178E.8090401@hfg-gmuend.de>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
	<563D178E.8090401@hfg-gmuend.de>
Message-ID: <F5384D66-FB06-4791-8F17-6498A005C33C@omniti.com>

A big drop like this likely will not be backported. It will appear in probably the second update to this bloody cycle, since the first drop is already frozen.

R151018 will be the first stable release to contain this.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Nov 6, 2015, at 4:11 PM, Guenther Alka <alka at hfg-gmuend.de> wrote:
> 
> Just saw the notice at Illumos IRC
> 
> Long awaited (Gordon Ross from Nexenta, gratulation, among others)
> SMB 2.1 is there - my Mac users will be happy
> 
> https://www.illumos.org/issues/6399
> https://www.illumos.org/issues/6398
> https://www.illumos.org/issues/6352
> https://www.illumos.org/issues/6400
> https://www.illumos.org/issues/1087
> 
> soon
> https://www.illumos.org/issues/3525
> 
> Pretty good news for OmniOS
> 
> 
> Two question
> - When -  will SMB 2.1 be included - to LTS or 151016??
> - Can 6352 support Primary and a Secondary AD Server as a failover - and how
> 
> Gea
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From cks at cs.toronto.edu  Fri Nov  6 23:10:03 2015
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Fri, 06 Nov 2015 18:10:03 -0500
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: Your message of Fri, 06 Nov 2015 09:17:35 +0200.
	<20151106071735.GI24984@gutsman.lotheac.fi>
Message-ID: <20151106231003.5A4A17A0939@apps0.cs.toronto.edu>

> Sure, generally speaking. In this particular context I believe users
> should ship their own if they want to deploy a mail server, but
> all nodes should be able to deliver mail locally. It would also be
> great if the default install lended itself to mail submission (eg.
> a satellite mailer configuration), perhaps even with opportunistic
> TLS, to cover more of the common use cases, but that might be just my
> personal bias talking.

 As a sysadmin, my vote is for a simple mailer setup of some sort that
will do either simple local delivery to /var/mail or 'smarthost' mail
submission to a full mailer somewhere else (we'd configure our OmniOS
machines to do the latter to our mail submission machine). I would be
fine with plain SMTP, with no AUTH support and no TLS. I do think that
'smarthost' mail submission should be capable enough to queue messages
and retry them if the smarthost is not reachable when the mail message
is initially generated.

(There are a whole lot of circumstances that can do this; imagine
crucial OmniOS machines on UPSes and a power failure, for example.)

	- cks

From lorban at bitronix.be  Sat Nov  7 08:26:36 2015
From: lorban at bitronix.be (Ludovic Orban)
Date: Sat, 7 Nov 2015 09:26:36 +0100
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <20151106231003.5A4A17A0939@apps0.cs.toronto.edu>
References: <20151106071735.GI24984@gutsman.lotheac.fi>
	<20151106231003.5A4A17A0939@apps0.cs.toronto.edu>
Message-ID: <CAN0RhANz4Puakmzpmf134E_zFt1GGBAn2Hhm+Tv=mQaf+Q2H5A@mail.gmail.com>

It looks like dma (the DragonFly BSD Mail Agent) would almost
perfectly fit that bill. The only problem I see with it is that it
depends on openssl to be able to connect to secured smtp servers, and
there doesn't seem to be an option to disable that in its build. It
shouldn't be rocket science to gut that out though.


On Sat, Nov 7, 2015 at 12:10 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
>> Sure, generally speaking. In this particular context I believe users
>> should ship their own if they want to deploy a mail server, but
>> all nodes should be able to deliver mail locally. It would also be
>> great if the default install lended itself to mail submission (eg.
>> a satellite mailer configuration), perhaps even with opportunistic
>> TLS, to cover more of the common use cases, but that might be just my
>> personal bias talking.
>
>  As a sysadmin, my vote is for a simple mailer setup of some sort that
> will do either simple local delivery to /var/mail or 'smarthost' mail
> submission to a full mailer somewhere else (we'd configure our OmniOS
> machines to do the latter to our mail submission machine). I would be
> fine with plain SMTP, with no AUTH support and no TLS. I do think that
> 'smarthost' mail submission should be capable enough to queue messages
> and retry them if the smarthost is not reachable when the mail message
> is initially generated.
>
> (There are a whole lot of circumstances that can do this; imagine
> crucial OmniOS machines on UPSes and a power failure, for example.)
>
>         - cks
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From alka at hfg-gmuend.de  Sat Nov  7 10:41:07 2015
From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=)
Date: Sat, 7 Nov 2015 11:41:07 +0100
Subject: [OmniOS-discuss] SMB 2.1 any many other improvements
In-Reply-To: <F5384D66-FB06-4791-8F17-6498A005C33C@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
	<563D178E.8090401@hfg-gmuend.de>
	<F5384D66-FB06-4791-8F17-6498A005C33C@omniti.com>
Message-ID: <563DD543.5090109@hfg-gmuend.de>

I will test the second bloody 151017 when it becomes available.

Hope for some explanations about how to join now correctly
and if it is possible and how to use a secondary AD server
in the Illumos wiki or the OmniOS wiki.

It is hard to find correct infos about new Illumos features
as the docs around are mostly related to Oracle or sometimes
extremely outdated like many entries in the Illumos wiki.

Sometimes you only find infos about new options in the OpenZFS
slides from some conference presentations or with discussions
@hardforum > data storage.. or @servethehome > Solaris..

A short reference with an example for essential new behaviours
or features would be extremely helpful. Maybe the release note
can include a short explanation for new features that require settings.

Thank you all very much


Gea



On 07.11.2015 00:06, Dan McDonald wrote:
> A big drop like this likely will not be backported. It will appear in probably the second update to this bloody cycle, since the first drop is already frozen.
>
> R151018 will be the first stable release to contain this.
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Nov 6, 2015, at 4:11 PM, Guenther Alka <alka at hfg-gmuend.de> wrote:
>>
>> Just saw the notice at Illumos IRC
>>
>> Long awaited (Gordon Ross from Nexenta, gratulation, among others)
>> SMB 2.1 is there - my Mac users will be happy
>>
>> https://www.illumos.org/issues/6399
>> https://www.illumos.org/issues/6398
>> https://www.illumos.org/issues/6352
>> https://www.illumos.org/issues/6400
>> https://www.illumos.org/issues/1087
>>
>> soon
>> https://www.illumos.org/issues/3525
>>
>> Pretty good news for OmniOS
>>
>>
>> Two question
>> - When -  will SMB 2.1 be included - to LTS or 151016??
>> - Can 6352 support Primary and a Secondary AD Server as a failover - and how
>>
>> Gea
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss


-- 

H          f   G
Hochschule f?r Gestaltung
university of design

Schw?bisch Gm?nd
Rektor Klaus Str. 100
73525 Schw?bisch Gm?nd

Guenther Alka, Dipl.-Ing. (FH)
Leiter des Rechenzentrums
head of computer center

Tel 07171 602 624
Fax 07171 69259
guenther.alka at hfg-gmuend.de
http://rz.hfg-gmuend.de


From rafibeyli at gmail.com  Sat Nov  7 18:42:52 2015
From: rafibeyli at gmail.com (Hafiz Rafiyev)
Date: Sat, 7 Nov 2015 20:42:52 +0200 (EET)
Subject: [OmniOS-discuss] Intel RAID Controller RS3UC080
In-Reply-To: <mailman.1585.1446850772.63303.omnios-discuss@lists.omniti.com>
References: <mailman.1585.1446850772.63303.omnios-discuss@lists.omniti.com>
Message-ID: <847164968.361754.1446921772523.JavaMail.zimbra@cantekstil.com.tr>

Hello,

Anyone has tested Intel RS3UC080 SAS3 HBA  12Gb card with OmniOS?

Basically it uses LSI3008 controller,planning to use with all SSD pool.

Thanks,

Hafiz

----- Orijinal Mesaj -----
Kimden: omnios-discuss-request at lists.omniti.com
Kime: "omnios-discuss" <omnios-discuss at lists.omniti.com>
G?nderilenler: 7 Kas?m Cumartesi 2015 1:59:32
Konu: OmniOS-discuss Digest, Vol 44, Issue 13

Send OmniOS-discuss mailing list submissions to
	omnios-discuss at lists.omniti.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.omniti.com/mailman/listinfo/omnios-discuss
or, via email, send a message with subject or body 'help' to
	omnios-discuss-request at lists.omniti.com

You can reach the person managing the list at
	omnios-discuss-owner at lists.omniti.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OmniOS-discuss digest..."


Today's Topics:

   1. Re: ILB memory leak? (Dan McDonald)
   2. Re: ILB memory leak? (Al Slater)
   3. Re: ILB memory leak? (Dan McDonald)
   4. Re: ILB memory leak? (Dan McDonald)
   5. Re: ILB memory leak? (Bob Friesenhahn)
   6. SMB 2.1 any many other improvements (Guenther Alka)
   7. Re: Bloody // mailwrapper & mta mediator (Paul B. Henson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 6 Nov 2015 10:43:35 -0500
From: Dan McDonald <danmcd at omniti.com>
To: Al Slater <al.slater at scluk.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <0C222003-AF3C-4BAB-A5ED-2748083B8F4B at omniti.com>
Content-Type: text/plain; charset=windows-1252


> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> 3D600000 1048576 1048576 1048576       - rwx--    [ anon ]
> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]

Hmmm.

I wonder if those are pre-allocated by libumem?  They're HUGE (1G) and more around them are smaller

Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?

Thanks,
Dan



------------------------------

Message: 2
Date: Fri, 6 Nov 2015 15:57:08 +0000
From: Al Slater <al.slater at scluk.com>
To: Dan McDonald <danmcd at omniti.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <563CCDD4.7040903 at scluk.com>
Content-Type: text/plain; charset=windows-1252

On 06/11/15 15:43, Dan McDonald wrote:
> 
>> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> 3D600000 1048576 1048576 1048576       - rwx--    [ anon ]
>> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
> 
> Hmmm.
> 
> I wonder if those are pre-allocated by libumem?  They're HUGE (1G) and more around them are smaller
> 
> Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?

No problem Dan, this is from a production ilbd that was restarted at
07:00 GMT

14585:  /usr/lib/inet/ilbd
 Address  Kbytes     RSS    Anon  Locked Mode   Mapped File
0802D000     108     108     108       - rw---    [ stack ]
08050000      76      76       -       - r-x--  ilbd
08073000       4       4       4       - rw---  ilbd
08074000      96       -       -       - rw---  ilbd
0808C000     252     248     244       - rw---    [ heap ]
7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
BDA00000  524288  524288  524288       - rwx--    [ anon ]
DDC00000  262144  262144  262144       - rwx--    [ anon ]
EDE00000  131072  131072  131072       - rwx--    [ anon ]
F6000000   65536   65536   65536       - rwx--    [ anon ]
FA200000   32768   32768   32768       - rwx--    [ anon ]
FC400000   16384   16384   16384       - rwx--    [ anon ]
FD600000    8192    8192    8192       - rwx--    [ anon ]
FE000000    4096    4096    4096       - rwx--    [ anon ]
FE600000    2048    2048    2048       - rwx--    [ anon ]
FE9A0000    1024    1024    1024       - rwx--    [ anon ]
FEAB0000     512     512     512       - rwx--    [ anon ]
FEB40000     256     256     256       - rwx--    [ anon ]
FEB90000     128     128     128       - rwx--    [ anon ]
FEBC0000      64      64      64       - rwx--    [ anon ]
FEBE0000      64      16      16       - rwx--    [ anon ]
FEC00000       4       4       4       - rwx--    [ anon ]
FEC10000      20      20       -       - r-x--  libilb.so.1
FEC25000       4       4       4       - rw---  libilb.so.1
FEC30000      32      32       -       - r-x--  libuutil.so.1
FEC48000       4       4       4       - rw---  libuutil.so.1
FEC50000       4       4       4       - rwx--    [ anon ]
FEC60000     172     172       -       - r-x--  libscf.so.1
FEC9B000       4       4       4       - rw---  libscf.so.1
FECA0000      20      20       -       - r-x--  libinetutil.so.1
FECB5000       4       4       4       - rw---  libinetutil.so.1
FECC0000       4       4       4       - rwx--    [ anon ]
FECD0000      20      20       -       - r-x--  libcmdutils.so.1
FECE5000       4       4       4       - rw---  libcmdutils.so.1
FECF0000       4       4       -       - r--s-  dev:528,9 ino:1532084444
FED00000      64      64       4       - rwx--    [ anon ]
FED20000      64      64       4       - rwx--    [ anon ]
FED40000     416     388       -       - r-x--  libnsl.so.1
FEDB8000       8       8       8       - rw---  libnsl.so.1
FEDBA000      20      12       -       - rw---  libnsl.so.1
FEDC0000       4       4       4       - rwx--    [ anon ]
FEDD0000      52      52       -       - r-x--  libsocket.so.1
FEDED000       4       4       4       - rw---  libsocket.so.1
FEDF0000      24      12      12       - rwx--    [ anon ]
FEE00000       4       4       4       - rwx--    [ anon ]
FEE10000    1252     888       -       - r-x--  libc_hwcap1.so.1
FEF59000      36      36      32       - rwx--  libc_hwcap1.so.1
FEF62000       8       8       8       - rwx--  libc_hwcap1.so.1
FEF70000       4       4       -       - r--s-  ld.config
FEF80000       4       4       4       - rwx--    [ anon ]
FEF90000       4       4       4       - rw---    [ anon ]
FEFA0000       4       4       4       - rw---    [ anon ]
FEFB0000       4       4       4       - rwx--    [ anon ]
FEFB5000     216     216       -       - r-x--  ld.so.1
FEFFB000       8       8       8       - rwx--  ld.so.1
FEFFD000       4       4       4       - rwx--  ld.so.1
-------- ------- ------- ------- -------
total Kb 2100192 2099632 2097600       -

Definitely no libumem:
root at thor:/export/home/BRIGHTON/aslate# pldd 14585
14585:  /usr/lib/inet/ilbd
/zones/roots/l1-lb1/root/usr/lib/libc/libc_hwcap1.so.1
/zones/roots/l1-lb1/root/lib/libsocket.so.1
/zones/roots/l1-lb1/root/lib/libnsl.so.1
/zones/roots/l1-lb1/root/lib/libcmdutils.so.1
/zones/roots/l1-lb1/root/lib/libinetutil.so.1
/zones/roots/l1-lb1/root/lib/libscf.so.1
/zones/roots/l1-lb1/root/lib/libuutil.so.1
/zones/roots/l1-lb1/root/usr/lib/libilb.so.1


-- 
Al Slater



------------------------------

Message: 3
Date: Fri, 6 Nov 2015 11:25:09 -0500
From: Dan McDonald <danmcd at omniti.com>
To: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <C84216BB-B2BD-4BFB-9477-E70D056F4D5E at omniti.com>
Content-Type: text/plain; charset=windows-1252


> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> 
> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
> BDA00000  524288  524288  524288       - rwx--    [ anon ]
> DDC00000  262144  262144  262144       - rwx--    [ anon ]
> EDE00000  131072  131072  131072       - rwx--    [ anon ]

More huge anonymous mappings (1G, 512MB, 256MB, 128MB).

I don't know pmap as well as I should.  I don't see anything in the man page to give me further insight into why these chunks of memory are being eaten.

Dan



------------------------------

Message: 4
Date: Fri, 6 Nov 2015 13:31:19 -0500
From: Dan McDonald <danmcd at omniti.com>
To: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <964395C2-376C-48A1-BFE8-A655EB667992 at omniti.com>
Content-Type: text/plain; charset=windows-1252


> On Nov 6, 2015, at 11:25 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
>> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
>> 
>> 
>> 7D800000 1048576 1048576 1048576       - rwx--    [ anon ]
>> BDA00000  524288  524288  524288       - rwx--    [ anon ]
>> DDC00000  262144  262144  262144       - rwx--    [ anon ]
>> EDE00000  131072  131072  131072       - rwx--    [ anon ]
> 
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
> 

You said you had a test box, right?

Can you:

- Disable UMEM_DEBUG
- RESTART the service.
- IMMEDIATELY after restart do pmap, and do pmap once per (sec, 10 sec, something) to see how it grows?

After that, maybe we can dtrace and see what's going on.

Dan



------------------------------

Message: 5
Date: Fri, 6 Nov 2015 12:33:47 -0600 (CST)
From: Bob Friesenhahn <bfriesen at simple.dallas.tx.us>
To: Dan McDonald <danmcd at omniti.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID:
	<alpine.GSO.2.01.1511061227120.20442 at freddy.simplesystems.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 6 Nov 2015, Dan McDonald wrote:
>
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
>
> I don't know pmap as well as I should.  I don't see anything in the 
> man page to give me further insight into why these chunks of memory 
> are being eaten.

It is pretty common for memory allocators to use anonymous mappings 
for large memory allocations.  This allows releasing memory back to 
the system.

Some applications use algorithms where they double the memory size 
request from the previous request when a little more memory is 
required in order to lessen the hit from many realloc() calls.  This 
might explain the power-of two sizes.  If this is being done, the 
smaller power of two allocations may be a bug.

Tracing mmap() calls on the program while is is running might reveal 
something.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


------------------------------

Message: 6
Date: Fri, 6 Nov 2015 22:11:42 +0100
From: Guenther Alka <alka at hfg-gmuend.de>
To: omnios-discuss at lists.omniti.com
Subject: [OmniOS-discuss] SMB 2.1 any many other improvements
Message-ID: <563D178E.8090401 at hfg-gmuend.de>
Content-Type: text/plain; charset=windows-1252; format=flowed

Just saw the notice at Illumos IRC

Long awaited (Gordon Ross from Nexenta, gratulation, among others)
SMB 2.1 is there - my Mac users will be happy

https://www.illumos.org/issues/6399
https://www.illumos.org/issues/6398
https://www.illumos.org/issues/6352
https://www.illumos.org/issues/6400
https://www.illumos.org/issues/1087

soon
https://www.illumos.org/issues/3525

Pretty good news for OmniOS


Two question
- When -  will SMB 2.1 be included - to LTS or 151016??
- Can 6352 support Primary and a Secondary AD Server as a failover - and how

Gea


------------------------------

Message: 7
Date: Fri, 06 Nov 2015 14:59:29 -0800
From: "Paul B. Henson" <henson at acm.org>
To: "'Dale Ghent'" <daleg at omniti.com>, "'Lauri Tirkkonen'"
	<lotheac at iki.fi>
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
Message-ID: <005401d118e6$cb7a9c50$626fd4f0$@acm.org>
Content-Type: text/plain; charset=us-ascii

> Dale Ghent
> Sent: Thursday, November 05, 2015 10:56 PM
>
> Well "do nothing" has been the apparent course of action for almost 6
years
> now. But that's speaking in general illumos-gate terms. As far as OmniOS
> goes, we can completely ignore that part of the tree and install our own
thing
> in our own way... but I want to at least explore the options which have a
> bearing on illumos-gate (ie; the greater illumos community) first.

>From a design perspective, I think the best option would be to rip sendmail
out of illumos-gate and replace it with something that just did simple local
mail delivery so the components of illumos-gate that require mail aren't
broken. Then distributions could add their own MTA of choice and/or allow
end-users to install other ones.



------------------------------

Subject: Digest Footer

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


------------------------------

End of OmniOS-discuss Digest, Vol 44, Issue 13
**********************************************

From mir at miras.org  Sat Nov  7 19:50:01 2015
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 7 Nov 2015 20:50:01 +0100
Subject: [OmniOS-discuss] Intel RAID Controller RS3UC080
In-Reply-To: <847164968.361754.1446921772523.JavaMail.zimbra@cantekstil.com.tr>
References: <mailman.1585.1446850772.63303.omnios-discuss@lists.omniti.com>
	<847164968.361754.1446921772523.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <20151107205001.1c48f0b2@sleipner.datanom.net>

On Sat, 7 Nov 2015 20:42:52 +0200 (EET)
Hafiz Rafiyev <rafibeyli at gmail.com> wrote:

> Hello,
> 
> Anyone has tested Intel RS3UC080 SAS3 HBA  12Gb card with OmniOS?
> 
> Basically it uses LSI3008 controller,planning to use with all SSD pool.
> 
AFAIK lsi3008 is fully supported in Illumos.

-- 
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:
Time is the most valuable thing a man can spend.
		-- Theophrastus
-------------- 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/20151107/3bf11f74/attachment.bin>

From bfriesen at simple.dallas.tx.us  Sun Nov  8 21:48:17 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Sun, 8 Nov 2015 15:48:17 -0600 (CST)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56391DE6.6050807@genashor.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<56391DE6.6050807@genashor.com>
Message-ID: <alpine.GSO.2.01.1511081544560.1673@freddy.simplesystems.org>

My first try at an update failed to boot properly.  Being a control 
freak, I had made /opt its own zfs filesystem.  Previously it must 
have been part of the boot environment.  The contents of /opt was not 
as expected and so the fs.local service failed.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From cks at cs.toronto.edu  Sun Nov  8 23:25:37 2015
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Sun, 08 Nov 2015 18:25:37 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: Your message of Sun, 08 Nov 2015 15:48:17 -0600.
	<alpine.GSO.2.01.1511081544560.1673@freddy.simplesystems.org>
Message-ID: <20151108232537.92A237A046D@apps0.cs.toronto.edu>

> My first try at an update failed to boot properly.  Being a control
> freak, I had made /opt its own zfs filesystem.  Previously it must
> have been part of the boot environment.  The contents of /opt was not
> as expected and so the fs.local service failed.

 We ran into this in our ongoing transition from r151010 to r151014,
where we initially had /opt as a separate ZFS filesystems in the root
pool. This caused unsolvable failures during the upgrade because /opt is
expected to be part of the boot environment and various things malfunction
if it isn't. I believe the general conclusion from the mailing list was
'a separate /opt is not a supported configuration and you can't do that'.

 Some more details for the curious are here:

	https://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSOptCaution

(I don't have a link to the discussion in the mailing list archives, but
interested parties should be able to dig it out without too much problem.)

	- cks

From bfriesen at simple.dallas.tx.us  Sun Nov  8 23:40:20 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Sun, 8 Nov 2015 17:40:20 -0600 (CST)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <20151108232537.92A237A046D@apps0.cs.toronto.edu>
References: <20151108232537.92A237A046D@apps0.cs.toronto.edu>
Message-ID: <alpine.GSO.2.01.1511081732550.1673@freddy.simplesystems.org>

On Sun, 8 Nov 2015, Chris Siebenmann wrote:
> if it isn't. I believe the general conclusion from the mailing list was
> 'a separate /opt is not a supported configuration and you can't do that'.
>
> Some more details for the curious are here:
>
> 	https://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSOptCaution

This is a really nice article.  It concludes that OmniOS owns /opt. 
I also see that pkgsrc owns /opt/local so there can be more owners 
than OmniOS.  I have learned that pkgsrc will automatically install 
services so it makes sense to leave it as part of the boot 
environment.

I was lucky enough to be able to quickly back-track, restore /opt in 
root, and retry.  It is all working now.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From tim at multitalents.net  Mon Nov  9 06:18:11 2015
From: tim at multitalents.net (Tim Rice)
Date: Sun, 8 Nov 2015 22:18:11 -0800 (PST)
Subject: [OmniOS-discuss] stable combinations of OmniOS 151014 andNFS to
 ESXi and state of open-vm tools (vmxnet3)
In-Reply-To: <A95747EB-424D-4332-BDC8-B975F428F23D@hfg-gmuend.de>
References: <1A3D1B20-9C33-4514-9956-5303F6BD320A@omniti.com>
	<A95747EB-424D-4332-BDC8-B975F428F23D@hfg-gmuend.de>
Message-ID: <alpine.UW2.2.11.1511082202260.911@server01.int.multitalents.net>


Hi G?nther,

On Tue, 11 Aug 2015, G?nther Alka wrote:

> In my own setups, I use OmniOS 151014 (initial release) with NFS to ESXi 5.5U2 which is very stable with vmxnet3 and e1000 (original VMware tools)
> In the last time I got several mails about problems on some configurations
> 
> Stable configurations
> 5.5U2 + OmniOS 151014  (April)
> 6.00b + OmniOS 151014  (April)
> 
> problems with
> 5.5U2 + OmniOS 151014  (July)
> 6.0 initial release + NFS
> 6.00b + OmniOS 151014  (July)
> 
> example
> http://hardforum.com/showpost.php?p=1041787564&postcount=6873 <http://hardforum.com/showpost.php?p=1041787564&postcount=6873>
> 
> 
> Are there others experiencing problems or stabiliy on these combinations?

Running ESXi 5.5U3 here.
Tonight on a r151014 (omnios-f090f73) VM using vmxnet3 nics, I updated
the vmware-tools from version 9.4.12 to 9.4.15. NFS performance between
the OmniOS NFS server and a Centos 5 NFS client dropped 2 orders of magnatude.
Reinstalling 9.4.12 made the system happy again.
Sorry I don't have time to dig deeper right now.

> 
> beside that
> Are there news about open vmware tools in OmniOS especially regarding the missing vmxnet3 driver

-- 
Tim Rice				Multitalents
tim at multitalents.net

From jimklimov at cos.ru  Mon Nov  9 08:59:02 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Mon, 09 Nov 2015 09:59:02 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <alpine.GSO.2.01.1511081732550.1673@freddy.simplesystems.org>
References: <20151108232537.92A237A046D@apps0.cs.toronto.edu>
	<alpine.GSO.2.01.1511081732550.1673@freddy.simplesystems.org>
Message-ID: <E65CF205-67B1-4F99-9CD0-1140C2882D17@cos.ru>

9 ?????? 2015??. 0:40:20 CET, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> ?????:
>On Sun, 8 Nov 2015, Chris Siebenmann wrote:
>> if it isn't. I believe the general conclusion from the mailing list
>was
>> 'a separate /opt is not a supported configuration and you can't do
>that'.
>>
>> Some more details for the curious are here:
>>
>> 	https://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSOptCaution
>
>This is a really nice article.  It concludes that OmniOS owns /opt. 
>I also see that pkgsrc owns /opt/local so there can be more owners 
>than OmniOS.  I have learned that pkgsrc will automatically install 
>services so it makes sense to leave it as part of the boot 
>environment.
>
>I was lucky enough to be able to quickly back-track, restore /opt in 
>root, and retry.  It is all working now.
>
>Bob

Technically, I believe OmniOS "owns" /opt/omni. Feel free to define other subdirs as datasets hosted elsewhere (out of tree of rootfs children). My own admin-scripts go under /opt but these are okay as part of rootfs/BE so I don't dataset them ;)

To manage split-off datasets of rootfs (children and shared) consider https://github.com/jimklimov/illumos-splitroot-scripts (shameless plug ;) ) 

This takes into account Firefly failsafe miniroots and PKGSrc datasets too.

Jim Klimov

--
Typos courtesy of K-9 Mail on my Samsung Android

From richard at netbsd.org  Mon Nov  9 09:59:11 2015
From: richard at netbsd.org (Richard PALO)
Date: Mon, 09 Nov 2015 10:59:11 +0100
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <alpine.GSO.2.01.1511081732550.1673@freddy.simplesystems.org>
References: <20151108232537.92A237A046D@apps0.cs.toronto.edu>
	<alpine.GSO.2.01.1511081732550.1673@freddy.simplesystems.org>
Message-ID: <56406E6F.2020000@netbsd.org>

Le 09/11/15 00:40, Bob Friesenhahn a ?crit :
> ... 
> I also see that pkgsrc owns /opt/local so there can be more owners 
> than OmniOS.  I have learned that pkgsrc will automatically install 
> services so it makes sense to leave it as part of the boot 
> environment.
> 

Just to be clear, pkgsrc doesn't "own" /opt/local at all. 

Bootstrap's default "prefix" is '/usr/pkg', or '$HOME/pkg' if specifying an unprivileged bootstrap. 

Many choose explicitly '--prefix=/usr/local' or perhaps '--prefix=/opt/local'.
Joyent's binary distribution uses the latter.

-- 
Richard PALO


From al.slater at scluk.com  Mon Nov  9 13:39:57 2015
From: al.slater at scluk.com (Al Slater)
Date: Mon, 09 Nov 2015 13:39:57 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <964395C2-376C-48A1-BFE8-A655EB667992@omniti.com>
References: <56276437.2020109@scluk.com>	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>	<563B3FB6.50000@scluk.com>	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>	<563C60CB.3060208@scluk.com>	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>	<563CC97E.9010108@scluk.com>	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>	<563CCDD4.7040903@scluk.com>	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<964395C2-376C-48A1-BFE8-A655EB667992@omniti.com>
Message-ID: <5640A22D.9000503@scluk.com>

Hi Dan,

On 06/11/2015 18:31, Dan McDonald wrote:
> You said you had a test box, right?

Yes.

> Can you:
>
> - Disable UMEM_DEBUG
> - RESTART the service.
> - IMMEDIATELY after restart do pmap, and do pmap once per (sec, 10 sec, something) to see how it grows?

Attached is a compressed file with 5hrs or so of 10s pmaps.  Hopefully 
not too big for the list.

> After that, maybe we can dtrace and see what's going on.



-- 
Al Slater

Technical Director
SCL

Phone : +44 (0)1273 666607
Fax   : +44 (0)1273 666601
email : al.slater at scluk.com

Stanton Consultancy Ltd

Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU

Registered in England Company number: 1957652 VAT number: GB 760 2433 55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmap.6589.gz
Type: application/gzip
Size: 59189 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151109/1864b8fd/attachment-0001.bin>

From danmcd at omniti.com  Mon Nov  9 15:43:12 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 9 Nov 2015 10:43:12 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <5640A22D.9000503@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<964395C2-376C-48A1-BFE8-A655EB667992@omniti.com>
	<5640A22D.9000503@scluk.com>
Message-ID: <FBB89ECC-A050-497C-B464-C3BCBE38EE57@omniti.com>


> On Nov 9, 2015, at 8:39 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> Attached is a compressed file with 5hrs or so of 10s pmaps.  Hopefully not too big for the list.

It compressed nicely.  I'm noticing a pattern:

Mon Nov  9 08:21:45 UTC 2015
total Kb  134008  133504  131416       -
Mon Nov  9 08:50:21 UTC 2015
total Kb  265080  264576  262488       -
Mon Nov  9 09:37:42 UTC 2015
total Kb  265088  264580  262492       -
Mon Nov  9 09:47:40 UTC 2015
total Kb  527232  526724  524636       -
Mon Nov  9 11:42:19 UTC 2015
total Kb 1051520 1050960 1048872       -
Mon Nov  9 11:42:29 UTC 2015
total Kb 1051520 1051012 1048924       -


It's mostly linear growth.  Notice the time intervals also double whenever the footprint essentially doubles?

So I need to back up and ask some things, especially given libumem doesn't appear to show leaks or even usage:

1.) Is the eating of memory affecting your system peformance?  (If you've only 8GB, yeah, I can see that.)

2.) Is ilb failing after it gets sufficiently large?

Dan


From cks at cs.toronto.edu  Mon Nov  9 15:52:35 2015
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Mon, 09 Nov 2015 10:52:35 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: jimklimov's message of Mon, 09 Nov 2015 09:59:02 +0100.
	<E65CF205-67B1-4F99-9CD0-1140C2882D17@cos.ru>
Message-ID: <20151109155235.970307A05B6@apps0.cs.toronto.edu>

> Technically, I believe OmniOS "owns" /opt/omni. Feel free to define
> other subdirs as datasets hosted elsewhere (out of tree of rootfs
> children). My own admin-scripts go under /opt but these are okay as
> part of rootfs/BE so I don't dataset them ;)

 OmniOS also puts stuff in eg /opt/gcc-4.8.1, which suggests that in
general all /opt/gcc-* names are potentially dangerous (since OmniOS
may change the supplied GCC versions at some point).

	- cks

From al.slater at scluk.com  Mon Nov  9 16:22:31 2015
From: al.slater at scluk.com (Al Slater)
Date: Mon, 9 Nov 2015 16:22:31 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <FBB89ECC-A050-497C-B464-C3BCBE38EE57@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<964395C2-376C-48A1-BFE8-A655EB667992@omniti.com>
	<5640A22D.9000503@scluk.com>
	<FBB89ECC-A050-497C-B464-C3BCBE38EE57@omniti.com>
Message-ID: <5640C847.3020600@scluk.com>

On 09/11/15 15:43, Dan McDonald wrote:
> 
>> On Nov 9, 2015, at 8:39 AM, Al Slater <al.slater at scluk.com> wrote:
>> 
>> Attached is a compressed file with 5hrs or so of 10s pmaps.
>> Hopefully not too big for the list.
> 
> It compressed nicely.  I'm noticing a pattern:
> 
> Mon Nov  9 08:21:45 UTC 2015 total Kb  134008  133504  131416
> - Mon Nov  9 08:50:21 UTC 2015 total Kb  265080  264576  262488
> - Mon Nov  9 09:37:42 UTC 2015 total Kb  265088  264580  262492
> - Mon Nov  9 09:47:40 UTC 2015 total Kb  527232  526724  524636
> - Mon Nov  9 11:42:19 UTC 2015 total Kb 1051520 1050960 1048872
> - Mon Nov  9 11:42:29 UTC 2015 total Kb 1051520 1051012 1048924
> -
> 
> 
> It's mostly linear growth.  Notice the time intervals also double
> whenever the footprint essentially doubles?
> 
> So I need to back up and ask some things, especially given libumem
> doesn't appear to show leaks or even usage:
> 
> 1.) Is the eating of memory affecting your system peformance?  (If
> you've only 8GB, yeah, I can see that.)

Hmmm...  I started investigating after the servers hung a couple of
times.  I have not conclusively proved that this was the cause, but the
machines have been running for months with no issue after I added a
cronjob to restart ilb twice a day.  I can see a gradual increase in
kernel memory use as well, but I have not investigated that.

> 2.) Is ilb failing after it gets sufficiently large?

Again, no link conclusively proved, but I did see log messages like the
following when the memory use had grown to 4Gb...

Nov  5 11:17:01 l1-lb2 ilbd[3041]: [ID 410242 daemon.error]
ilbd_hc_probe_timer: cannot restart timer: rule ggp server _ggp.11,
disabling it

I looked at the source for ilbd and I think this could be caused by a
memory allocation failure in iu_schedule_timer.

After these messages was generated, it looks like the disabled servers
were never re-enabled, so eventually this could end up with no enabled
servers, and therefore no service, without manual intervention.

-- 
Al Slater


From bfriesen at simple.dallas.tx.us  Mon Nov  9 17:01:59 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Mon, 9 Nov 2015 11:01:59 -0600 (CST)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <20151109155235.970307A05B6@apps0.cs.toronto.edu>
References: <20151109155235.970307A05B6@apps0.cs.toronto.edu>
Message-ID: <alpine.GSO.2.01.1511091058010.20442@freddy.simplesystems.org>

On Mon, 9 Nov 2015, Chris Siebenmann wrote:

>> Technically, I believe OmniOS "owns" /opt/omni. Feel free to define
>> other subdirs as datasets hosted elsewhere (out of tree of rootfs
>> children). My own admin-scripts go under /opt but these are okay as
>> part of rootfs/BE so I don't dataset them ;)
>
> OmniOS also puts stuff in eg /opt/gcc-4.8.1, which suggests that in
> general all /opt/gcc-* names are potentially dangerous (since OmniOS
> may change the supplied GCC versions at some point).

In fact, it did change the supplied GCC version in this release. 
Older versions remain installed but are attributed to previous 
releases.  The GCC development packages need to be explicitly 
requested for installaion.

I did have to explicitly request to install GCC 5.1.0.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From danmcd at omniti.com  Mon Nov  9 22:05:09 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 9 Nov 2015 17:05:09 -0500
Subject: [OmniOS-discuss] Bloody now at r151017
Message-ID: <1F5D878E-4E06-428B-9B77-6A237D1425F7@omniti.com>

Over the weekend I'd updated the repo, and I just pushed out new install media for the r151017 version of bloody.

Not a LOT new here over r151016, save for some illumos-gate merges (a couple of which will make it into both r151014 and r151016 later this week).

Read our Installation page:

	http://omnios.omniti.com/wiki.php/Installation

for links to the ISO, USB-DD, or kayak .bz2.zfs.

Dan


From al.slater at scluk.com  Tue Nov 10 07:40:17 2015
From: al.slater at scluk.com (Al Slater)
Date: Tue, 10 Nov 2015 07:40:17 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
References: <56276437.2020109@scluk.com>	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>	<563B3FB6.50000@scluk.com>	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>	<563C60CB.3060208@scluk.com>	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>	<563CC97E.9010108@scluk.com>	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>	<563CCDD4.7040903@scluk.com>	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
Message-ID: <56419F61.2050905@scluk.com>

On 06/11/2015 18:33, Bob Friesenhahn wrote:
> Tracing mmap() calls on the program while is is running might reveal
> something.

Tracing mmap calls with dtrace gives me the following stack, called 
roughly the same number of times as there are doubled-in-size anon 
mappings in the mmap output.

               libc.so.1`mmap
               libc.so.1`lmalloc+0x168
               libc.so.1`posix_spawn_file_actions_addclose+0x2f
               ilbd`ilbd_run_probe+0x19b
               ilbd`ilbd_hc_probe_timer+0x10

Looking at the source for lmalloc (1), it implements the allocation 
attributes we are seeing.

Now, looking at posix_spawn_file_actions_addclose (2), this allocates a 
file_attr_t which is added to the file_actions list (which was stack 
allocated as fd_actions in ilbd_run_probe (3) and inititialized with 
posix_spawn_file_actions_init.

After fd_actions is passed to posix_spawn, I can't see anywhere calling 
posix_spawn_file_actions_destroy to clean up the list.

It seems to me that ilbd_run_probe just needs to call 
posix_spawn_file_actions_destroy appropriately.


(1) /usr/src/lib/libc/port/threads/alloc.c
(2) /usr/src/lib/libc/port/threads/spawn.c
(3) /usr/src/cmd/cmd-inet/usr.lib/ilbd/ilbd_hc.c

-- 
Al Slater




From al.slater at scluk.com  Tue Nov 10 07:50:06 2015
From: al.slater at scluk.com (Al Slater)
Date: Tue, 10 Nov 2015 07:50:06 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <56419F61.2050905@scluk.com>
References: <56276437.2020109@scluk.com>	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>	<563B3FB6.50000@scluk.com>	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>	<563C60CB.3060208@scluk.com>	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>	<563CC97E.9010108@scluk.com>	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>	<563CCDD4.7040903@scluk.com>	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
	<56419F61.2050905@scluk.com>
Message-ID: <5641A1AE.6030808@scluk.com>

On 10/11/2015 07:40, Al Slater wrote:
> It seems to me that ilbd_run_probe just needs to call
> posix_spawn_file_actions_destroy appropriately.

And probably posix_spawnattr_destroy as well?

-- 
Al Slater

Technical Director
SCL

Phone : +44 (0)1273 666607
Fax   : +44 (0)1273 666601
email : al.slater at scluk.com

Stanton Consultancy Ltd

Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU

Registered in England Company number: 1957652 VAT number: GB 760 2433 55


From danmcd at omniti.com  Tue Nov 10 15:26:10 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 10 Nov 2015 10:26:10 -0500
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <5641A1AE.6030808@scluk.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
	<56419F61.2050905@scluk.com> <5641A1AE.6030808@scluk.com>
Message-ID: <A3C238CC-EE86-450F-8664-9B20F8D5457C@omniti.com>


> On Nov 10, 2015, at 2:50 AM, Al Slater <al.slater at scluk.com> wrote:
> 
> On 10/11/2015 07:40, Al Slater wrote:
>> It seems to me that ilbd_run_probe just needs to call
>> posix_spawn_file_actions_destroy appropriately.
> 
> And probably posix_spawnattr_destroy as well?

Wow!  Great catch.  I'll bet a small sum you nailed this to the wall.

Want me to build you a replacement ilbd?

Dan


From al.slater at scluk.com  Tue Nov 10 15:33:15 2015
From: al.slater at scluk.com (Al Slater)
Date: Tue, 10 Nov 2015 15:33:15 +0000
Subject: [OmniOS-discuss] ILB memory leak?
In-Reply-To: <A3C238CC-EE86-450F-8664-9B20F8D5457C@omniti.com>
References: <56276437.2020109@scluk.com>
	<00AE5FA3-E699-4C4F-8A94-AEEDAAED0856@omniti.com>
	<563B3FB6.50000@scluk.com>
	<88C2CA91-632F-4216-B467-2F66451623AA@omniti.com>
	<563C60CB.3060208@scluk.com>
	<56E6D034-0061-44BD-92A7-9AD1A984A816@omniti.com>
	<5FCAD305-C737-4618-BEC7-1EE2195BF624@omniti.com>
	<563CC97E.9010108@scluk.com>
	<0C222003-AF3C-4BAB-A5ED-2748083B8F4B@omniti.com>
	<563CCDD4.7040903@scluk.com>
	<C84216BB-B2BD-4BFB-9477-E70D056F4D5E@omniti.com>
	<alpine.GSO.2.01.1511061227120.20442@freddy.simplesystems.org>
	<56419F61.2050905@scluk.com> <5641A1AE.6030808@scluk.com>
	<A3C238CC-EE86-450F-8664-9B20F8D5457C@omniti.com>
Message-ID: <56420E3B.3020002@scluk.com>

On 10/11/15 15:26, Dan McDonald wrote:
> 
>> On Nov 10, 2015, at 2:50 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> On 10/11/2015 07:40, Al Slater wrote:
>>> It seems to me that ilbd_run_probe just needs to call
>>> posix_spawn_file_actions_destroy appropriately.
>>
>> And probably posix_spawnattr_destroy as well?
> 
> Wow!  Great catch.  I'll bet a small sum you nailed this to the wall.
> 
> Want me to build you a replacement ilbd?

Yes please :)

Thanks for your, and Bob's, help with this.

-- 
Al Slater


From richard at netbsd.org  Tue Nov 10 19:42:57 2015
From: richard at netbsd.org (Richard PALO)
Date: Tue, 10 Nov 2015 20:42:57 +0100
Subject: [OmniOS-discuss] and now what ... getting back to the gate
Message-ID: <n1thc2$j52$1@ger.gmane.org>

Well, this bloody update went fine from a gate build, reset sticky to omnios and setting non-sticky to on-nightly ... the pkg update goes hunky dory.

So now I'm in a BE where all is pure omnios again.
> richard at omnis:/home/richard$ uname -a
> SunOS omnis 5.11 omnios-2a4e66a i86pc i386 i86pc

build the gate (well, illumos-omnios to avoid...)
and now I'd like to go back current.

so I reset sticky to on-nightly and non-sticky to omnios

> richard at omnis:/home/richard$ LANG=C pkg publisher
> PUBLISHER                   TYPE     STATUS P LOCATION
> omnios         (non-sticky) origin   online F http://pkg.omniti.com/omnios/bloody/
> on-nightly                  origin   online F file:///home/richard/src/illumos-gate/packages/i386/nightly//repo.redist/

check that my build is more recent (w.a.c here)

> richard at omnis:/home/richard$ LANG=C pfexec pkg list -avf text/locale 
> FMRI                                                                         IFO
> pkg://omnios/text/locale at 0.5.11-0.151017:20151106T014232Z                    i--
> pkg://on-nightly/text/locale at 0.5.11-0.151017:20151110T183129Z                ---

and go for it
> richard at omnis:/home/richard$ LANG=C pfexec pkg update -v --be-name b151017-20151110
> No updates available for this image.

dang, what's up?
-- 
Richard PALO



From danmcd at omniti.com  Tue Nov 10 20:54:27 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 10 Nov 2015 15:54:27 -0500
Subject: [OmniOS-discuss] and now what ... getting back to the gate
In-Reply-To: <n1thc2$j52$1@ger.gmane.org>
References: <n1thc2$j52$1@ger.gmane.org>
Message-ID: <36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>


> On Nov 10, 2015, at 2:42 PM, Richard PALO <richard at netbsd.org> wrote:
> 
> 
> and go for it
>> richard at omnis:/home/richard$ LANG=C pfexec pkg update -v --be-name b151017-20151110
>> No updates available for this image.
> 
> dang, what's up?

I usually retarget the omnios publisher itself, but what you did SHOULD work.

If you specify a package, assuming you want entire... run "pkg update" specifying entire.

	... pkg update -v --be-name .... entire

and see why pkg(5) is not letting you.  Or select a series of packages with timestamps from on-nightly, and specify those, seeing why pkg(5) won't let you.

And why didn't you just try the /opt/onbld/bin/onu command?

Dan


From richard at netbsd.org  Tue Nov 10 21:10:11 2015
From: richard at netbsd.org (Richard PALO)
Date: Tue, 10 Nov 2015 22:10:11 +0100
Subject: [OmniOS-discuss] and now what ... getting back to the gate
In-Reply-To: <36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
References: <n1thc2$j52$1@ger.gmane.org>
	<36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
Message-ID: <56425D33.5040604@netbsd.org>

Le 10/11/15 21:54, Dan McDonald a ?crit :
> 
>> On Nov 10, 2015, at 2:42 PM, Richard PALO <richard-S783fYmB3Ccdnm+yROfE0A at public.gmane.org> wrote:
>>
>>
>> and go for it
>>> richard at omnis:/home/richard$ LANG=C pfexec pkg update -v --be-name b151017-20151110
>>> No updates available for this image.
>>
>> dang, what's up?
> 
> I usually retarget the omnios publisher itself, but what you did SHOULD work.
> 
> If you specify a package, assuming you want entire... run "pkg update" specifying entire.
> 
> 	... pkg update -v --be-name .... entire
> 
> and see why pkg(5) is not letting you.  Or select a series of packages with timestamps from on-nightly, and specify those, seeing why pkg(5) won't let you.
> 
> And why didn't you just try the /opt/onbld/bin/onu command?
> 
> Dan
> 

Well, I believe entire is for when I want to go back to the omnios distro, not to my gate...

But trying onu was enticing:
> richard at omnis:/home/richard/src/illumos-gate$ pfexec /opt/onbld/bin/onu  -t b151017-20151110 -v -d packages/i386/nightly
> beadm create b151017-20151110
> Created successfully
> beadm mount b151017-20151110 /tmp/onu.6AaajK
> Mounted successfully on: '/tmp/onu.6AaajK'
> pkg -R /tmp/onu.6AaajK set-publisher --no-refresh --set-property signature-policy=verify --non-sticky omnios
> pkg -R /tmp/onu.6AaajK set-publisher -e --no-refresh -P --set-property signature-policy=verify -O file:///home/richard/src/illumos-gate/packages/i386/nightly/repo.redist on-nightly
> pkg -R /tmp/onu.6AaajK refresh --full
> pkg -R /tmp/onu.6AaajK image-update
> Packages ? mettre ? jour : 330
> 
> TELECHARGEMENT                      PACKAGES      FICHIERS    XFER (Mo) VITESSE
> Termin?                             330/330     2339/2339    88.2/88.2    0o/s
> 
> PHASE                                       ELEMENTS
> Suppression des anciennes actions                2/2
> Installation des nouvelles actions               3/3
> Mise ? jour des actions modifi?es        4131/4131
> Mise ? jour de la base de donn?es d'?tat des packages    Termin? 
> Mise ? jour du cache de packages            330/330 
> Mise ? jour de l'?tat des images          Termin? 
> Cr?ation d'une base de donn?es de recherche rapide    Termin? 
> 
> ---------------------------------------------------------------------------
> REMARQUE : consultez les notes de version disponibles ? la page :
> 
> http://omnios.omniti.com/ReleaseNotes
> ---------------------------------------------------------------------------
> 
> beadm activate b151017-20151110
> Activated successfully
> /opt/onbld/bin/onu[124]: [: ']' missing
> WARNING: Use of onu(1) will prevent use of zone attach in the new BE
> See onu(1)
> Updating zone zoneadm
> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky
> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky failed: exit code 1

what's all this last business?  
-- 
Richard PALO


From skeltonr at btconnect.com  Tue Nov 10 21:16:13 2015
From: skeltonr at btconnect.com (Richard Skelton)
Date: Tue, 10 Nov 2015 21:16:13 +0000
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
Message-ID: <56425E9D.4040209@btconnect.com>

Hi Dan,
I am using the CD iso r151016 image and the installer drops back to the
installation menu if I select the Europe time zone.
If I select UTC/GMT the installer continues to the next screen "Date and
Time"
This did work in previous releases.

Dan McDonald wrote:
> Say hello to OmniOS r151016:
>
> 	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151016
>
> The big highlights include:
>
> 	- Userland now compiled with gcc5.1.
>
> 	- New and complete "illumos-tools" package available for more expedient illumos development
>
> 	- netperf and iperf now available for all of your network measuring needs.
>
> 	- Up to date with October illumos-gate
>
> 	- New installs get OpenSSH by default, and OpenSSH is now easier to switch to or from.  (Thanks to Lauri "lotheac" Tirkkonen for this!)
>
> OmniOS r151016 is the next Stable release.  r151014 now assumes its role as LTS.  (There will be an r151014 update later this week, with one bugfix from illumos-gate that needs to be brought back.)
>
> If you took advantage of linked-image zones in r151014, make sure you read the upgrade instructions.  You can do it more quickly than in the past, but it requires a bit of setup.
>
> Thank you to the OmniOS community for your feedback and support!
> Dan McDonald -- OmniOS Engineering
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>   

From richard at netbsd.org  Tue Nov 10 21:20:37 2015
From: richard at netbsd.org (Richard PALO)
Date: Tue, 10 Nov 2015 22:20:37 +0100
Subject: [OmniOS-discuss] and now what ... getting back to the gate
In-Reply-To: <56425D33.5040604@netbsd.org>
References: <n1thc2$j52$1@ger.gmane.org>	<36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
	<56425D33.5040604@netbsd.org>
Message-ID: <56425FA5.2010504@netbsd.org>

Le 10/11/15 22:10, Richard PALO a ?crit :
> Le 10/11/15 21:54, Dan McDonald a ?crit :
>>
>>> On Nov 10, 2015, at 2:42 PM, Richard PALO <richard-S783fYmB3Ccdnm+yROfE0A at public.gmane.org> wrote:
>>>
>>>
>>> and go for it
>>>> richard at omnis:/home/richard$ LANG=C pfexec pkg update -v --be-name b151017-20151110
>>>> No updates available for this image.
>>>
>>> dang, what's up?
>>
>> I usually retarget the omnios publisher itself, but what you did SHOULD work.
>>
>> If you specify a package, assuming you want entire... run "pkg update" specifying entire.
>>
>> 	... pkg update -v --be-name .... entire
>>
>> and see why pkg(5) is not letting you.  Or select a series of packages with timestamps from on-nightly, and specify those, seeing why pkg(5) won't let you.
>>
>> And why didn't you just try the /opt/onbld/bin/onu command?
>>
>> Dan
>>
> 
> Well, I believe entire is for when I want to go back to the omnios distro, not to my gate...
> 
> But trying onu was enticing:
>> richard at omnis:/home/richard/src/illumos-gate$ pfexec /opt/onbld/bin/onu  -t b151017-20151110 -v -d packages/i386/nightly
>> beadm create b151017-20151110
>> Created successfully
>> beadm mount b151017-20151110 /tmp/onu.6AaajK
>> Mounted successfully on: '/tmp/onu.6AaajK'
>> pkg -R /tmp/onu.6AaajK set-publisher --no-refresh --set-property signature-policy=verify --non-sticky omnios
>> pkg -R /tmp/onu.6AaajK set-publisher -e --no-refresh -P --set-property signature-policy=verify -O file:///home/richard/src/illumos-gate/packages/i386/nightly/repo.redist on-nightly
>> pkg -R /tmp/onu.6AaajK refresh --full
>> pkg -R /tmp/onu.6AaajK image-update
>> Packages ? mettre ? jour : 330
>>
>> TELECHARGEMENT                      PACKAGES      FICHIERS    XFER (Mo) VITESSE
>> Termin?                             330/330     2339/2339    88.2/88.2    0o/s
>>
>> PHASE                                       ELEMENTS
>> Suppression des anciennes actions                2/2
>> Installation des nouvelles actions               3/3
>> Mise ? jour des actions modifi?es        4131/4131
>> Mise ? jour de la base de donn?es d'?tat des packages    Termin? 
>> Mise ? jour du cache de packages            330/330 
>> Mise ? jour de l'?tat des images          Termin? 
>> Cr?ation d'une base de donn?es de recherche rapide    Termin? 
>>
>> ---------------------------------------------------------------------------
>> REMARQUE : consultez les notes de version disponibles ? la page :
>>
>> http://omnios.omniti.com/ReleaseNotes
>> ---------------------------------------------------------------------------
>>
>> beadm activate b151017-20151110
>> Activated successfully
>> /opt/onbld/bin/onu[124]: [: ']' missing
>> WARNING: Use of onu(1) will prevent use of zone attach in the new BE
>> See onu(1)
>> Updating zone zoneadm
>> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
>> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky
>> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
>> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky failed: exit code 1
> 
> what's all this last business?  
> 


Tried onu again with '-Z' to avoid my zone and it seems to have worked.

I do notice that onu seems to have left the new BE mounted, which I thought was
fixed back in the OI days...

If no issues, then this is okay for now given it's a one-time thing for me.
-- 
Richard PALO


From danmcd at omniti.com  Tue Nov 10 21:25:57 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 10 Nov 2015 16:25:57 -0500
Subject: [OmniOS-discuss] and now what ... getting back to the gate
In-Reply-To: <56425D33.5040604@netbsd.org>
References: <n1thc2$j52$1@ger.gmane.org>
	<36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
	<56425D33.5040604@netbsd.org>
Message-ID: <171A7FAE-6FE1-4D38-8EDA-6DA74ABCD63A@omniti.com>


> On Nov 10, 2015, at 4:10 PM, Richard PALO <richard at netbsd.org> wrote:
> 
>> 
>> beadm activate b151017-20151110
>> Activated successfully
>> /opt/onbld/bin/onu[124]: [: ']' missing
>> WARNING: Use of onu(1) will prevent use of zone attach in the new BE
>> See onu(1)
>> Updating zone zoneadm
>> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
>> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky
>> pkg: Aucune image ne se trouve ? l'emplacement 'zoneadm/root'
>> pkg -R zoneadm/root set-publisher --no-refresh --set-property signature-policy=verify --non-sticky failed: exit code 1
> 
> what's all this last business?  

A bug in ONU, it seems...

What's weird, however, is that it should work.  update_zone() is invoked thusly:

        for zone in `do_cmd zoneadm -R $tmpdir list -cip`; do
                update_zone $zone
        done

What does "zoneadm list -cip" say for you?

Dan


From danmcd at omniti.com  Tue Nov 10 22:16:50 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 10 Nov 2015 17:16:50 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <56425E9D.4040209@btconnect.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<56425E9D.4040209@btconnect.com>
Message-ID: <140450AB-E642-4C0C-A060-2C76F67DFB8A@omniti.com>


> On Nov 10, 2015, at 4:16 PM, Richard Skelton <skeltonr at btconnect.com> wrote:
> 
> Hi Dan,
> I am using the CD iso r151016 image and the installer drops back to the
> installation menu if I select the Europe time zone.
> If I select UTC/GMT the installer continues to the next screen "Date and
> Time"
> This did work in previous releases.

I've selected US, and then Eastern and it worked.  And I picked Europe, and it indeed failed.  Interesting.  Also failing:

	Africa
	Indian Ocean

It appears to be a problem with the installer program listing out timezones:

Traceback (most recent call last):
  File "/usr/lib/python2.6/vendor-packages/solaris_install/text_install/__init__.py", line 420, in main
    screen = screen.show()
  File "/usr/lib/python2.6/vendor-packages/terminalui/base_screen.py", line 149, in show
    self._show()
  File "/usr/lib/python2.6/vendor-packages/solaris_install/sysconfig/timezone.py", line 162, in _show
    text=timezone, data_obj=timezone)
  File "/usr/lib/python2.6/vendor-packages/terminalui/list_item.py", line 58, in __init__
    self.set_text(text, centered)
  File "/usr/lib/python2.6/vendor-packages/terminalui/list_item.py", line 67, in set_text
    centered=centered)
  File "/usr/lib/python2.6/vendor-packages/terminalui/inner_window.py", line 349, in add_text
    text = fit_text_truncate(text, max_chars)
  File "/usr/lib/python2.6/vendor-packages/terminalui/i18n.py", line 118, in fit_text_truncate
    text = text.decode(get_encoding())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

I'll need to dig down into this.

A workaround is to install UTC as your timezone, reboot to the new system, then edit /etc/default/init to change the system's default timezone, and reboot again to correct the timezone.

Dan


From danmcd at omniti.com  Tue Nov 10 22:30:30 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 10 Nov 2015 17:30:30 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <140450AB-E642-4C0C-A060-2C76F67DFB8A@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<56425E9D.4040209@btconnect.com>
	<140450AB-E642-4C0C-A060-2C76F67DFB8A@omniti.com>
Message-ID: <A17B4CA7-6499-4B1C-9653-504BB75AFED0@omniti.com>


> On Nov 10, 2015, at 5:16 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> I'll need to dig down into this.

I found it.

This fix:

commit bf8c2c3ce2a697c5bbe04f2b83f770cf9a59c981
Author: Dan McDonald <danmcd at omniti.com>
Date:   Tue Oct 27 09:01:54 2015 -0400

    6402 Update zoneinfo to 2015g

Included a country.tab from ASCII into UTF-8.  This breaks libzoneinfo, and subsequently the installer.

I think for now I'll have to revert this portion of the change.  And here's an illumos bug for the deeper problem:

	https://www.illumos.org/issues/6453

There's an 016 update coming soon.  I'll add the reversion to it.

Dan


From jimklimov at cos.ru  Tue Nov 10 23:26:53 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Wed, 11 Nov 2015 00:26:53 +0100
Subject: [OmniOS-discuss] and now what ... getting back to the gate
In-Reply-To: <36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
References: <n1thc2$j52$1@ger.gmane.org>
	<36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com>
Message-ID: <7E73510F-271B-4D7F-8C3A-1FE098D725B7@cos.ru>

10 ?????? 2015??. 21:54:27 CET, Dan McDonald <danmcd at omniti.com> ?????:
>
>> On Nov 10, 2015, at 2:42 PM, Richard PALO <richard at netbsd.org> wrote:
>> 
>> 
>> and go for it
>>> richard at omnis:/home/richard$ LANG=C pfexec pkg update -v --be-name
>b151017-20151110
>>> No updates available for this image.
>> 
>> dang, what's up?
>
>I usually retarget the omnios publisher itself, but what you did SHOULD
>work.
>
>If you specify a package, assuming you want entire... run "pkg update"
>specifying entire.
>
>	... pkg update -v --be-name .... entire
>
>and see why pkg(5) is not letting you.  Or select a series of packages
>with timestamps from on-nightly, and specify those, seeing why pkg(5)
>won't let you.
>
>And why didn't you just try the /opt/onbld/bin/onu command?
>
>Dan
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

I believe specifying package FMRI including @version can help install the specific package and whatever it wants. Also you may be well served with full fmri's including the publisher name. Helps me when switching between local and upstream builds, though lately on smaller scale (bits of userspace getting upstreamed).

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From danmcd at omniti.com  Wed Nov 11 20:22:44 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 11 Nov 2015 15:22:44 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
Message-ID: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>

As the first non-upstream-merge change for the r151017 bloody cycle, I'm hoping to update java from openjdk7 to openjdk8.

Now obviously there will be some illumos-omnios factors (poold, the lone java holdout in illumos), but I'm more curious about how you, the community, use openjdk in OmniOS.

Feel free to dump advice on this thread.  I'm nowhere near ready for a bloody update with openjdk8 yet, but since I'm starting, I figure early feedback is better.

Thanks!
Dan


From danmcd at omniti.com  Wed Nov 11 21:58:34 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 11 Nov 2015 16:58:34 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
Message-ID: <F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>


> On Nov 11, 2015, at 4:50 PM, Ben Summers <ben at bens.me.uk> wrote:
> 
> I've always assumed that using the built in java is a KYSTY violation, and using it would rely too much on OmniTI keeping it bang up to date. So we package our own.

To be fair, it's there solely to enable the last bits of illumos that need it (poold, I believe is the sole survivor).

The big reason I can think of to update it involves vulnerability patching.

Dan


From peter.tribble at gmail.com  Wed Nov 11 23:17:38 2015
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 11 Nov 2015 23:17:38 +0000
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
Message-ID: <CAEgYsbGxAkDM9dKT3ShLsQvrX3OF5PeZa8vf3H+GwoEdkpLvmA@mail.gmail.com>

On Wed, Nov 11, 2015 at 8:22 PM, Dan McDonald <danmcd at omniti.com> wrote:

> As the first non-upstream-merge change for the r151017 bloody cycle, I'm
> hoping to update java from openjdk7 to openjdk8.
>
> Now obviously there will be some illumos-omnios factors (poold, the lone
> java holdout in illumos), but I'm more curious about how you, the
> community, use openjdk in OmniOS.
>
> Feel free to dump advice on this thread.  I'm nowhere near ready for a
> bloody update with openjdk8 yet, but since I'm starting, I figure early
> feedback is better.
>

(I see that Ben already mentioned that we don't use the bundled version on
our
omnios machines. So below relates to the issues I faced when contemplating
the same upgrade for my own distro.)

As 32-bit, 64-bit, or dual personality?

I think that's the thing that's likely to be "interesting", although I
guess most
people wouldn't notice.

I'm a little confused by the current openjdk7 that's shipped, which appears
to
be 32-bit only.

The default jdk8 is 64-bit, although it is possible to build a 32-bit
version. I
haven't tried creating a dual-personality openjdk8 package, I'm not even
sure
it's possible.

One request in the openjdk area - can you populate the cacerts file?

-- 
-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/20151111/191d599e/attachment.html>

From jimklimov at cos.ru  Thu Nov 12 12:08:17 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Thu, 12 Nov 2015 13:08:17 +0100
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <CAEgYsbGxAkDM9dKT3ShLsQvrX3OF5PeZa8vf3H+GwoEdkpLvmA@mail.gmail.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<CAEgYsbGxAkDM9dKT3ShLsQvrX3OF5PeZa8vf3H+GwoEdkpLvmA@mail.gmail.com>
Message-ID: <73D39164-4616-4A0E-B769-741DB8C258B0@cos.ru>

12 ?????? 2015??. 0:17:38 CET, Peter Tribble <peter.tribble at gmail.com> ?????:
>On Wed, Nov 11, 2015 at 8:22 PM, Dan McDonald <danmcd at omniti.com>
>wrote:
>
>> As the first non-upstream-merge change for the r151017 bloody cycle,
>I'm
>> hoping to update java from openjdk7 to openjdk8.
>>
>> Now obviously there will be some illumos-omnios factors (poold, the
>lone
>> java holdout in illumos), but I'm more curious about how you, the
>> community, use openjdk in OmniOS.
>>
>> Feel free to dump advice on this thread.  I'm nowhere near ready for
>a
>> bloody update with openjdk8 yet, but since I'm starting, I figure
>early
>> feedback is better.
>>
>
>(I see that Ben already mentioned that we don't use the bundled version
>on
>our
>omnios machines. So below relates to the issues I faced when
>contemplating
>the same upgrade for my own distro.)
>
>As 32-bit, 64-bit, or dual personality?
>
>I think that's the thing that's likely to be "interesting", although I
>guess most
>people wouldn't notice.
>
>I'm a little confused by the current openjdk7 that's shipped, which
>appears
>to
>be 32-bit only.
>
>The default jdk8 is 64-bit, although it is possible to build a 32-bit
>version. I
>haven't tried creating a dual-personality openjdk8 package, I'm not
>even
>sure
>it's possible.
>
>One request in the openjdk area - can you populate the cacerts file?

There's a couple cents from me twoo ;)

Dual-personality (-d32 and -d64) - yes both please. There are small services written in Java mostly for portability rather than scalability. They do not require 4g+ VM space, but would suffer (consume noticeably mkre hist memory) from largish 64-bit pointers all over the stack.

Also, a showstopper for Oracle JDK8u25 and 8u11 on my laptop in a particular usecase for me was that Netbeans 8.0.2 won't start up (cleanly) with "The package containing the class javax.swing.JComponentBeanInfo was not found". Same issue  with OpenJDK7 (1.7.0_080 oi internal), but works ok with Oracle JDK 7u65. Note that to test this, export netbeans_jdkhome=... rather than common JAVA_HOME.

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From ben at fluffy.co.uk  Thu Nov 12 12:20:02 2015
From: ben at fluffy.co.uk (Ben Summers)
Date: Thu, 12 Nov 2015 12:20:02 +0000
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <73D39164-4616-4A0E-B769-741DB8C258B0@cos.ru>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<CAEgYsbGxAkDM9dKT3ShLsQvrX3OF5PeZa8vf3H+GwoEdkpLvmA@mail.gmail.com>
	<73D39164-4616-4A0E-B769-741DB8C258B0@cos.ru>
Message-ID: <04079048-5B7F-4F4F-AD44-0924FF1A8CDE@fluffy.co.uk>


> On 12 Nov 2015, at 12:08, Jim Klimov <jimklimov at cos.ru> wrote:
> 
> There's a couple cents from me twoo ;)
> 
> Dual-personality (-d32 and -d64) - yes both please. There are small services written in Java mostly for portability rather than scalability. They do not require 4g+ VM space, but would suffer (consume noticeably mkre hist memory) from largish 64-bit pointers all over the stack.

On x64, with heaps under 4GB, Java uses compressed OOPs (object pointers) which only take up 32 bits and use a fancy x86 addressing mode to work just as fast as 64 bit pointers.

They removed 32 bit support from Solaris Java because there didn't seem to be much point. 64 bit didn't take up more memory, and went faster because of the better instruction set.

Of course if you have a 32 bit server, or want to use JNI with 32 bit binaries, that's little consolation.

Ben



From ben at fluffy.co.uk  Thu Nov 12 12:20:05 2015
From: ben at fluffy.co.uk (Ben Summers)
Date: Thu, 12 Nov 2015 12:20:05 +0000
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
Message-ID: <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>


> On 11 Nov 2015, at 21:58, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Nov 11, 2015, at 4:50 PM, Ben Summers <ben at bens.me.uk> wrote:
>> 
>> I've always assumed that using the built in java is a KYSTY violation, and using it would rely too much on OmniTI keeping it bang up to date. So we package our own.
> 
> To be fair, it's there solely to enable the last bits of illumos that need it (poold, I believe is the sole survivor).
> 
> The big reason I can think of to update it involves vulnerability patching.

And that's why I don't think it's possible to use the built in one for anything. Are you committing to getting a Java update out the same day as Oracle?

Ben



From danmcd at omniti.com  Thu Nov 12 15:29:08 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 12 Nov 2015 10:29:08 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
Message-ID: <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>


> On Nov 12, 2015, at 7:20 AM, Ben Summers <ben at fluffy.co.uk> wrote:
> 
> And that's why I don't think it's possible to use the built in one for anything. Are you committing to getting a Java update out the same day as Oracle?

That's an excellent point.  I'm not.

Given that the built-in java is only used for poold, perhaps I should spend my time elsewhere. I'm also running into openjdk8 doing things new&differently that REALLY mess up existing assumptions in build.sh.  :)

I may hold off on this, then.

Thanks,
Dan


From eric.sproul at circonus.com  Thu Nov 12 16:08:35 2015
From: eric.sproul at circonus.com (Eric Sproul)
Date: Thu, 12 Nov 2015 11:08:35 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
Message-ID: <CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>

On Thu, Nov 12, 2015 at 10:29 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
>> On Nov 12, 2015, at 7:20 AM, Ben Summers <ben at fluffy.co.uk> wrote:
>>
>> And that's why I don't think it's possible to use the built in one for anything. Are you committing to getting a Java update out the same day as Oracle?
>
> That's an excellent point.  I'm not.
>
> Given that the built-in java is only used for poold, perhaps I should spend my time elsewhere. I'm also running into openjdk8 doing things new&differently that REALLY mess up existing assumptions in build.sh.  :)

The Java landscape is also confusing as heck these days, given Oracle
Java SE vs. OpenJDK.  *Oracle* is no longer publicly updating Java SE
7, but *OpenJDK* 7 appears to still be getting updates, but I've been
unable to locate any sort of end date for OpenJDK's "jdk7u" project.
I guess this means that security updates will still come out for
OpenJDK 7?

Eric

From danmcd at omniti.com  Thu Nov 12 18:34:33 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 12 Nov 2015 13:34:33 -0500
Subject: [OmniOS-discuss] Can't see Europe in installs? Plus new workaround
Message-ID: <E02DA6DD-F233-4E8E-A1E8-47BB488456C9@omniti.com>

There are two distinct problems with the r151016 installer, recently pointed out as "If I select Europe, the installer dies".

PROBLEM 1 --> 2015g uses UTF-8 now.  --> This is not really a bug, but it does expose problems in the OmniOS Caiman code.

PROBLEM 2 --> OmniOS Caiman code has a bug.  This is basically the language-selection code at the beginning (when you select your keyboard type) is totally broken, and always defaults to the C locale. The short answer is to import this patch: https://github.com/OpenIndiana/slim_source/commit/e70c8327f1d7c168d0ee03d11b7f90204eb8271b  into the OmniOS Caiman.  I'm working on this now.

You can workaround ALL of these by:

	- Going to the shell.
	- Uttering:   LANG=<your-favorite.UTF8> text-install

which will give you the text installer again, but with a proper UTF8 locale, so it won't barf on the input.

Once I fix problem 2 OR you select the workaround, there is a third problem that results:  if you select a continent/region with UTF-8 non-ASCII characters, the text installer renders rather oddly.  I'm attaching a picture below.


Just wanted to give you all an update.  We're still waiting for an external-source update before we spin 014 and 016 updates, so pardon the delay.

Thanks,
Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151112/b4f44799/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-11-12 at 1.34.09 PM.png
Type: image/png
Size: 34330 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151112/b4f44799/attachment-0001.png>

From lorban at bitronix.be  Fri Nov 13 10:47:03 2015
From: lorban at bitronix.be (Ludovic Orban)
Date: Fri, 13 Nov 2015 11:47:03 +0100
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
Message-ID: <CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>

Quite frankly I wouldn't bother with a JDK 8 upgrade. JDK 8 is not
100% backwards compatible despite what Oracle says and IMHO the last
bits of code in gate that rely on java should be gutted or rewritten.

Here is what I would do: stick to KYSTY by eventually upgrading to the
latest OpenJDK 7 and telling users to install their own JDK if they
want to use java as at some time in the future, OpenJDK won't be
bundled anymore.

On Thu, Nov 12, 2015 at 5:08 PM, Eric Sproul <eric.sproul at circonus.com> wrote:
> On Thu, Nov 12, 2015 at 10:29 AM, Dan McDonald <danmcd at omniti.com> wrote:
>>
>>> On Nov 12, 2015, at 7:20 AM, Ben Summers <ben at fluffy.co.uk> wrote:
>>>
>>> And that's why I don't think it's possible to use the built in one for anything. Are you committing to getting a Java update out the same day as Oracle?
>>
>> That's an excellent point.  I'm not.
>>
>> Given that the built-in java is only used for poold, perhaps I should spend my time elsewhere. I'm also running into openjdk8 doing things new&differently that REALLY mess up existing assumptions in build.sh.  :)
>
> The Java landscape is also confusing as heck these days, given Oracle
> Java SE vs. OpenJDK.  *Oracle* is no longer publicly updating Java SE
> 7, but *OpenJDK* 7 appears to still be getting updates, but I've been
> unable to locate any sort of end date for OpenJDK's "jdk7u" project.
> I guess this means that security updates will still come out for
> OpenJDK 7?
>
> Eric
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From danmcd at omniti.com  Fri Nov 13 12:48:25 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 13 Nov 2015 07:48:25 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
Message-ID: <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>


> On Nov 13, 2015, at 5:47 AM, Ludovic Orban <lorban at bitronix.be> wrote:
> 
> Quite frankly I wouldn't bother with a JDK 8 upgrade. JDK 8 is not
> 100% backwards compatible despite what Oracle says and IMHO the last
> bits of code in gate that rely on java should be gutted or rewritten.
> 
> Here is what I would do: stick to KYSTY by eventually upgrading to the
> latest OpenJDK 7 and telling users to install their own JDK if they
> want to use java as at some time in the future, OpenJDK won't be
> bundled anymore.

Well put, and what is actually going to happen.

So... anyone care to rewrite poold?!?  :)

Dan


From danmcd at omniti.com  Fri Nov 13 20:13:47 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 13 Nov 2015 15:13:47 -0500
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
Message-ID: <C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>

Hello everyone!

I've updated the pkg servers and the install media with updates for r151014 & r151016.

Highlights include:

016:
-----

- Changing of sendmail in entire.p5m from "require" to "group" (which allows a user to uninstall it).
- illumos 6439 (handles KVM guests better)
- KVM updates
- Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
- LSI Fury support
- ilbd memory leak plug.


014:
------

- OpenSSH 7.1p1, including the r151016 method(s) of changing between SunSSH and OpenSSH
- Git update to 2.6.1
- tmux update
- illumos 6439 (handles KVM guests better)
- KVM updates
- Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
- LSI Fury support
- TCP timestamping behavior fix (illumos 5850)
- uuidgen(1M) now available
- HW data update to match r151016.
- Several small ZFS fixes (illumos 5219,6288,6267,6367,6319,6385,6334,6386)
- Aggregates no longer attempt to use downed links (illumos 6274)
- glob(3c) now properly deals with large-file 32-bit binaries (you may need to locally recompile your custom 32-bit apps)
- Zoneinfo update to 2015g
- ilbd memory leak plug


Happy updating!
Dan



From geoffn at gnaa.net  Fri Nov 13 20:26:07 2015
From: geoffn at gnaa.net (Geoff Nordli)
Date: Fri, 13 Nov 2015 12:26:07 -0800
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
Message-ID: <5646475F.9010608@gnaa.net>

Hi.

I am migrating a couple of machines from OI to OmniOS.

Is it possible to install omnios into a new boot environment so I can 
keep both the install of OI and then boot between them?

thanks,

Geoff



From danmcd at omniti.com  Fri Nov 13 20:36:49 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 13 Nov 2015 15:36:49 -0500
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
In-Reply-To: <5646475F.9010608@gnaa.net>
References: <5646475F.9010608@gnaa.net>
Message-ID: <416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>


> On Nov 13, 2015, at 3:26 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Hi.
> 
> I am migrating a couple of machines from OI to OmniOS.
> 
> Is it possible to install omnios into a new boot environment so I can keep both the install of OI and then boot between them?

Wow.  I don't know.  It's *theoretically possible* but I think you'd have to install OmniOS on a VM, zfs snapshot-and-send the rpool/ROOT/<be> to the OI box, and manually construct an OmniOS BE around that received ZFS snapshot, including adding GRUB entries.

Haven't tried it myself.

Dan


From chip at innovates.com  Fri Nov 13 20:48:36 2015
From: chip at innovates.com (Schweiss, Chip)
Date: Fri, 13 Nov 2015 14:48:36 -0600
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
Message-ID: <CALeZrrRagcaoCUDo46JLN8nhoiU4XrYqtrU-F0fDLrA6Hx+jVA@mail.gmail.com>

On Fri, Nov 13, 2015 at 2:13 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> 014:
> ------
>
> - OpenSSH 7.1p1, including the r151016 method(s) of changing between
> SunSSH and OpenSSH
>
>
Thank you for this!!

-Chip


>
> Happy updating!
> Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151113/82767f3d/attachment.html>

From gary at genashor.com  Fri Nov 13 21:24:31 2015
From: gary at genashor.com (Gary Gendel)
Date: Fri, 13 Nov 2015 16:24:31 -0500
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
Message-ID: <5646550F.8080706@genashor.com>

After upgrading I've got a conflict between smb and apcupsd (the ups 
monitor program from pkgsrc). They both want to lock the usb port that 
the ups is hung on.

The actual smb process that holds the lock is svc:/network/shares/group:smb

Is there a way to tell this process not to hook to this port?  I 
wouldn't think it would have since the device is not a storage unit.  I 
temporarily resolved this by stopping the smb process to start the 
apcupsd process, then start that one.

Alternatively, is it possible to force the smb process start after the 
apcupsd one?

Thanks,
Gary

On 11/13/2015 03:13 PM, Dan McDonald wrote:
> Hello everyone!
>
> I've updated the pkg servers and the install media with updates for r151014 & r151016.
>
> Highlights include:
>
> 016:
> -----
>
> - Changing of sendmail in entire.p5m from "require" to "group" (which allows a user to uninstall it).
> - illumos 6439 (handles KVM guests better)
> - KVM updates
> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
> - LSI Fury support
> - ilbd memory leak plug.
>
>
> 014:
> ------
>
> - OpenSSH 7.1p1, including the r151016 method(s) of changing between SunSSH and OpenSSH
> - Git update to 2.6.1
> - tmux update
> - illumos 6439 (handles KVM guests better)
> - KVM updates
> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
> - LSI Fury support
> - TCP timestamping behavior fix (illumos 5850)
> - uuidgen(1M) now available
> - HW data update to match r151016.
> - Several small ZFS fixes (illumos 5219,6288,6267,6367,6319,6385,6334,6386)
> - Aggregates no longer attempt to use downed links (illumos 6274)
> - glob(3c) now properly deals with large-file 32-bit binaries (you may need to locally recompile your custom 32-bit apps)
> - Zoneinfo update to 2015g
> - ilbd memory leak plug
>
>
> Happy updating!
> Dan
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3699 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151113/36d36d73/attachment-0001.bin>

From jimklimov at cos.ru  Fri Nov 13 23:09:04 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Sat, 14 Nov 2015 00:09:04 +0100
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
In-Reply-To: <416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
References: <5646475F.9010608@gnaa.net>
	<416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
Message-ID: <A93421FA-84CC-4DCB-AE36-76AA600A343A@cos.ru>

13 ?????? 2015??. 21:36:49 CET, Dan McDonald <danmcd at omniti.com> ?????:
>
>> On Nov 13, 2015, at 3:26 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>> 
>> Hi.
>> 
>> I am migrating a couple of machines from OI to OmniOS.
>> 
>> Is it possible to install omnios into a new boot environment so I can
>keep both the install of OI and then boot between them?
>
>Wow.  I don't know.  It's *theoretically possible* but I think you'd
>have to install OmniOS on a VM, zfs snapshot-and-send the
>rpool/ROOT/<be> to the OI box, and manually construct an OmniOS BE
>around that received ZFS snapshot, including adding GRUB entries.
>
>Haven't tried it myself.
>
>Dan
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

That's roughly what I did when migrating a machine from SXCE to OI, I think I left some breadcrumbs on mailing lists and/or wiki to keep note of important files etc. that required attention ;)

Hopefully, with software as close as OmniOS and OI (especially if you use bleeding edges of both projects) there will be much less hassle with system files and services. On another hand, note that OmniOS repos (even the additional ones) ship much less userland software than OI, so you'd probably have to install pkgsrc and semi-manually upgrade it when new releases come out.

BTW, see if beadm create'ing an empty BE, pkg -R adding omnios publishers into it, and installing 'entire' would do some magic? Also, IIRC there are zfs.bz2 images of OmniOS for caiman wnat are these? Pre-fabricated installations?

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From hasslerd at gmx.li  Fri Nov 13 23:15:02 2015
From: hasslerd at gmx.li (Dominik Hassler)
Date: Sat, 14 Nov 2015 00:15:02 +0100
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
Message-ID: <56466EF6.70103@gmx.li>

 > - KVM updates

does this include VND, yet?

On 11/13/2015 09:13 PM, Dan McDonald wrote:
> Hello everyone!
>
> I've updated the pkg servers and the install media with updates for r151014 & r151016.
>
> Highlights include:
>
> 016:
> -----
>
> - Changing of sendmail in entire.p5m from "require" to "group" (which allows a user to uninstall it).
> - illumos 6439 (handles KVM guests better)
> - KVM updates
> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
> - LSI Fury support
> - ilbd memory leak plug.
>
>
> 014:
> ------
>
> - OpenSSH 7.1p1, including the r151016 method(s) of changing between SunSSH and OpenSSH
> - Git update to 2.6.1
> - tmux update
> - illumos 6439 (handles KVM guests better)
> - KVM updates
> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
> - LSI Fury support
> - TCP timestamping behavior fix (illumos 5850)
> - uuidgen(1M) now available
> - HW data update to match r151016.
> - Several small ZFS fixes (illumos 5219,6288,6267,6367,6319,6385,6334,6386)
> - Aggregates no longer attempt to use downed links (illumos 6274)
> - glob(3c) now properly deals with large-file 32-bit binaries (you may need to locally recompile your custom 32-bit apps)
> - Zoneinfo update to 2015g
> - ilbd memory leak plug
>
>
> Happy updating!
> Dan
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From jimklimov at cos.ru  Fri Nov 13 23:14:55 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Sat, 14 Nov 2015 00:14:55 +0100
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <5646550F.8080706@genashor.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
	<5646550F.8080706@genashor.com>
Message-ID: <320AC536-C88A-4A2C-8CF1-B9649F9F4ABB@cos.ru>

13 ?????? 2015??. 22:24:31 CET, Gary Gendel <gary at genashor.com> ?????:
>After upgrading I've got a conflict between smb and apcupsd (the ups 
>monitor program from pkgsrc). They both want to lock the usb port that 
>the ups is hung on.
>
>The actual smb process that holds the lock is
>svc:/network/shares/group:smb
>
>Is there a way to tell this process not to hook to this port?  I 
>wouldn't think it would have since the device is not a storage unit.  I
>
>temporarily resolved this by stopping the smb process to start the 
>apcupsd process, then start that one.
>
>Alternatively, is it possible to force the smb process start after the 
>apcupsd one?
>
>Thanks,
>Gary
>
>On 11/13/2015 03:13 PM, Dan McDonald wrote:
>> Hello everyone!
>>
>> I've updated the pkg servers and the install media with updates for
>r151014 & r151016.
>>
>> Highlights include:
>>
>> 016:
>> -----
>>
>> - Changing of sendmail in entire.p5m from "require" to "group" (which
>allows a user to uninstall it).
>> - illumos 6439 (handles KVM guests better)
>> - KVM updates
>> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
>> - LSI Fury support
>> - ilbd memory leak plug.
>>
>>
>> 014:
>> ------
>>
>> - OpenSSH 7.1p1, including the r151016 method(s) of changing between
>SunSSH and OpenSSH
>> - Git update to 2.6.1
>> - tmux update
>> - illumos 6439 (handles KVM guests better)
>> - KVM updates
>> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
>> - LSI Fury support
>> - TCP timestamping behavior fix (illumos 5850)
>> - uuidgen(1M) now available
>> - HW data update to match r151016.
>> - Several small ZFS fixes (illumos
>5219,6288,6267,6367,6319,6385,6334,6386)
>> - Aggregates no longer attempt to use downed links (illumos 6274)
>> - glob(3c) now properly deals with large-file 32-bit binaries (you
>may need to locally recompile your custom 32-bit apps)
>> - Zoneinfo update to 2015g
>> - ilbd memory leak plug
>>
>>
>> Happy updating!
>> Dan
>>
>>
>> _______________________________________________
>> 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

> Alternatively, is it possible to force the smb process start after the smb one?

Are these wrapped into SMF instances? Then yes, easily: use 'svccfg -s servicename editprop' or 'svccfg export svcname > file.xml; vi ... ; svccfg import file.xml' to define (maybe optional) dependencies between the two.

HTH,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From danmcd at omniti.com  Sat Nov 14 03:51:49 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 13 Nov 2015 22:51:49 -0500
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <56466EF6.70103@gmx.li>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
	<56466EF6.70103@gmx.li>
Message-ID: <E08D4DEB-2707-450A-9EEE-5B9C57EBBB5F@omniti.com>

Not yet.  They were security fixes.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Nov 13, 2015, at 6:15 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
> 
> > - KVM updates
> 
> does this include VND, yet?
> 
>> On 11/13/2015 09:13 PM, Dan McDonald wrote:
>> Hello everyone!
>> 
>> I've updated the pkg servers and the install media with updates for r151014 & r151016.
>> 
>> Highlights include:
>> 
>> 016:
>> -----
>> 
>> - Changing of sendmail in entire.p5m from "require" to "group" (which allows a user to uninstall it).
>> - illumos 6439 (handles KVM guests better)
>> - KVM updates
>> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
>> - LSI Fury support
>> - ilbd memory leak plug.
>> 
>> 
>> 014:
>> ------
>> 
>> - OpenSSH 7.1p1, including the r151016 method(s) of changing between SunSSH and OpenSSH
>> - Git update to 2.6.1
>> - tmux update
>> - illumos 6439 (handles KVM guests better)
>> - KVM updates
>> - Hans Rosenfeld's blkdev series of fixes (illumos 6299-6305)
>> - LSI Fury support
>> - TCP timestamping behavior fix (illumos 5850)
>> - uuidgen(1M) now available
>> - HW data update to match r151016.
>> - Several small ZFS fixes (illumos 5219,6288,6267,6367,6319,6385,6334,6386)
>> - Aggregates no longer attempt to use downed links (illumos 6274)
>> - glob(3c) now properly deals with large-file 32-bit binaries (you may need to locally recompile your custom 32-bit apps)
>> - Zoneinfo update to 2015g
>> - ilbd memory leak plug
>> 
>> 
>> Happy updating!
>> Dan
>> 
>> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> 

From info at houseofancients.nl  Sun Nov 15 19:36:43 2015
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Sun, 15 Nov 2015 19:36:43 +0000
Subject: [OmniOS-discuss] otherwise stable system sudden crashing
Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC9597B93@vEX01.mindstorm-internet.local>

Hi All,

After some further investigation, found something that may be of importance to some.
Found out this system also had a cifs share, serving out some media files to a Openelec 6.0 Kodi media center.
That Media center coincidentally was shut down the same time I restarted the Esx machines

When starting and browsing a smb session from that linux system, immediately OmniOS crashes with the below crash report.
When doing the same from a windows 7, xp , 8.1 and 2012 machine the OmniOS keep running as expected.

Are the any other having the same issues ?
If someone wants the complete crash report, let me know

Kr,

Floris

Van: Floris van Essen ..:: House of Ancients Amstafs ::..
Verzonden: zaterdag 14 november 2015 20:21
Aan: OmniOS-discuss <omnios-discuss-bounces at lists.omniti.com>
Onderwerp: otherwise stable system sudden crashing

Hi All,

Just had something strange happen, and would like to pick some of you minds.
Updated OmniOS v11 r151016 yesterday.

Basically it runs as a ISCSI storage backend to 2 VMWare Esx 5.5 build 2638301 hosts.

This system has been running extremely stable for over 2 years now, until this evening.
Out of the blue started rebooting, with a kernel dumps.

Log shows :

Nov 14 19:05:38 PSD01 genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=ffffff0079ff6710 addr=0 occurred in module "unix" due to a NULL pointer dereference
Nov 14 19:05:38 PSD01 unix: [ID 100000 kern.notice]
Nov 14 19:05:38 PSD01 unix: [ID 839527 kern.notice] sched:
Nov 14 19:05:38 PSD01 unix: [ID 753105 kern.notice] #pf Page fault
Nov 14 19:05:38 PSD01 unix: [ID 532287 kern.notice] Bad kernel fault at addr=0x0
Nov 14 19:05:38 PSD01 unix: [ID 243837 kern.notice] pid=0, pc=0xfffffffffb854cf8, sp=0xffffff0079ff6808, eflags=0x10286
Nov 14 19:05:38 PSD01 unix: [ID 211416 kern.notice] cr0: 8005003b cr4: 406f8
Nov 14 19:05:38 PSD01 unix: [ID 624947 kern.notice] cr2: 0
Nov 14 19:05:38 PSD01 unix: [ID 625075 kern.notice] cr3: c000000
Nov 14 19:05:38 PSD01 unix: [ID 625715 kern.notice] cr8: c
Nov 14 19:05:38 PSD01 unix: [ID 100000 kern.notice]
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       rdi:               10 rsi: ffffff11678f6828 rdx:               10
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       rcx:              178  r8:                0  r9:                0
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       rax: ffffff11678f6818 rbx: ffffff115e6d7168 rbp: ffffff0079ff6860
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       r10: fffffffffb854cf8 r11:                2 r12: ffffff1155fe7650
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       r13: ffffff1167903ea8 r14: ffffff1164c9b288 r15: ffffff11678d18e0
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       fsb:                0 gsb: ffffff1142c83b00  ds:               4b
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]        es:               4b  fs:                0  gs:              1c3
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]       trp:                e err:                0 rip: fffffffffb854cf8
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]        cs:               30 rfl:            10286 rsp: ffffff0079ff6808
Nov 14 19:05:38 PSD01 unix: [ID 266532 kern.notice]        ss:               38
Nov 14 19:05:38 PSD01 unix: [ID 100000 kern.notice]
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff65f0 unix:die+df ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6700 unix:trap+dc0 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6710 unix:cmntrap+e6 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6860 unix:bcopy+1a8 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6990 smbsrv:smb_authenticate_core+3cb ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff69e0 smbsrv:smb_authenticate+44 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6a60 smbsrv:smb_com_session_setup_andx+2e ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6b50 smbsrv:smb_dispatch_request+5c5 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6b90 smbsrv:smb_session_worker+a0 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6c20 genunix:taskq_d_thread+b7 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ffffff0079ff6c30 unix:thread_start+8 ()
Nov 14 19:05:38 PSD01 unix: [ID 100000 kern.notice]
Nov 14 19:05:38 PSD01 genunix: [ID 672855 kern.notice] syncing file systems...
Nov 14 19:05:39 PSD01 genunix: [ID 904073 kern.notice]  done
Nov 14 19:05:40 PSD01 genunix: [ID 111219 kern.notice] dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
Nov 14 19:06:55 PSD01 genunix: [ID 100000 kern.notice]
Nov 14 19:06:55 PSD01 genunix: [ID 665016 kern.notice] ^M100% done: 876666 pages dumped,
Nov 14 19:06:55 PSD01 genunix: [ID 851671 kern.notice] dump succeeded

Ran hardware diagnostics, no errors found, let the system boot, boot dump again.
Not until I rebooted both VMWare hosts, the OmniOS returned to a normal and stable state.
Any idea what's going on ?
Were the any updates to the COMSTAR or the SMB server?

Kr,

Floris



...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151115/3800e962/attachment-0001.html>

From wonko at 4amlunch.net  Sun Nov 15 20:13:54 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Sun, 15 Nov 2015 15:13:54 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on SuperMicro
	X8DTL-3F
Message-ID: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>

I?ve got a X8DTL-3F that I?m attempting to install OmniOS onto.

The installer wouldn?t see the 4x SAS disks connected to the onboard LSI 1068e. prtconf -d showed that the driver wasn?t getting attached to the card.

I flashed the controller with the IT firmware to see if that would help (and as I wanted to do that anyway).

This has led to the following situation:

1) It still shows the LSI card as (driver not attached)
2) The BIOS no longer sees the disks on the 1068e as bootable

This is really super frustrating. :(

How do I get these drives seen by OmniOS? (and bootable!)

Additionally (while I have your attention) there are a pair of NVMe drives in PCIe adapters that are also showing up as (driver not attached) that I would really like to get working as those are to be my SLOG devices. Samsung SM951 if it matters.

-brian

From bfriesen at simple.dallas.tx.us  Sun Nov 15 20:40:55 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Sun, 15 Nov 2015 14:40:55 -0600 (CST)
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
 SuperMicro X8DTL-3F
In-Reply-To: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
Message-ID: <alpine.GSO.2.01.1511151433090.1673@freddy.simplesystems.org>

On Sun, 15 Nov 2015, Brian Hechinger wrote:

> I?ve got a X8DTL-3F that I?m attempting to install OmniOS onto.
>
> The installer wouldn?t see the 4x SAS disks connected to the onboard 
> LSI 1068e. prtconf -d showed that the driver wasn?t getting attached 
> to the card.

What is the storage size of the disks?  This controller has a disk 
size limit.

> How do I get these drives seen by OmniOS? (and bootable!)
>
> Additionally (while I have your attention) there are a pair of NVMe 
> drives in PCIe adapters that are also showing up as (driver not 
> attached) that I would really like to get working as those are to be 
> my SLOG devices. Samsung SM951 if it matters.

I have AHCI versions of the Samsung SM951 here that OmniOS sees and 
installed onto.  It took a BIOS update (SuperMicro) before the BIOS 
also saw the devices and could boot from them.  This is in a Xeon 
D-1450 based system.

Even with AHCI (rather than NVMe), zfs scrub reports a scrub rate 
exceeding 1.3GB/s across a pair of these devices.  They would be 
fantastic as L2ARC devices.

The NVMe driver is really new so perhaps not many devices are 
automatically recognized yet.

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 Nov 15 22:16:05 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Sun, 15 Nov 2015 17:16:05 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: Your message of "Sun, 15 Nov 2015 15:13:54 EST."
	<9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> 
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> 
Message-ID: <201511152216.tAFMG59o016126@elvis.arl.psu.edu>

In message <9F7A6807-3818-4668-8CAF-D023DAABFBC7 at 4amlunch.net>, Brian Hechinger
 writes:
>The installer wouldn't see the 4x SAS disks connected to the onboard LSI 1068e.
> prtconf -d showed that the driver wasn't getting attached to the card.
>
>I flashed the controller with the IT firmware to see if that would help (and a
>s I wanted to do that anyway).

On cold-boot to FreeDOS, does LSI's sasflash still list the HBA?
And if so, which firmware?

>This has led to the following situation:
>
>1) It still shows the LSI card as (driver not attached)
>2) The BIOS no longer sees the disks on the 1068e as bootable
>
>This is really super frustrating. :(
>
>How do I get these drives seen by OmniOS? (and bootable!)

$ prtconf -pv|egrep 'pci.*1000'

And confirm it is listed in /etc/driver_aliases

John
groenveld at acm.rog

From wonko at 4amlunch.net  Sun Nov 15 22:52:57 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Sun, 15 Nov 2015 17:52:57 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <201511152216.tAFMG59o016126@elvis.arl.psu.edu>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
Message-ID: <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>


> On Nov 15, 2015, at 5:16 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> 
> In message <9F7A6807-3818-4668-8CAF-D023DAABFBC7 at 4amlunch.net>, Brian Hechinger
> writes:
>> The installer wouldn't see the 4x SAS disks connected to the onboard LSI 1068e.
>> prtconf -d showed that the driver wasn't getting attached to the card.
>> 
>> I flashed the controller with the IT firmware to see if that would help (and a
>> s I wanted to do that anyway).
> 
> On cold-boot to FreeDOS, does LSI's sasflash still list the HBA?

Just checked, and yes.

1068E(B3)

> And if so, which firmware?

01.30.00.00 (IT)

> 
>> This has led to the following situation:
>> 
>> 1) It still shows the LSI card as (driver not attached)
>> 2) The BIOS no longer sees the disks on the 1068e as bootable
>> 
>> This is really super frustrating. :(
>> 
>> How do I get these drives seen by OmniOS? (and bootable!)
> 
> $ prtconf -pv|egrep 'pci.*1000'
> 
> And confirm it is listed in /etc/driver_aliases

So what I see is from ?prtconf -d | grep LSI? are two number: pci15d9,6 (pciex1000,59)

Both of those are listed in the output of "prtconf -pv|egrep 'pci.*1000??

Neither are in /etc/driver_aliases

Adding pciex1000,59 to mpt results in this at boot:

WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
                 LSI PCI device (1000,59) not supported.
WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
                 mpt_config_space_init failed
WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
                 attach failed

I can re-flash this to IR and see what the result is there, but something tells me it?s going to be the same (other than the BIOS showing those drives again)

-brian

From wonko at 4amlunch.net  Sun Nov 15 23:08:06 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Sun, 15 Nov 2015 18:08:06 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
Message-ID: <A6446D18-7135-45F4-A9E9-4F2C830884E5@4amlunch.net>


> On Nov 15, 2015, at 5:52 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> I can re-flash this to IR and see what the result is there, but something tells me it?s going to be the same (other than the BIOS showing those drives again)

Or not because the flash util crashes. :(

-brian

From jdg117 at elvis.arl.psu.edu  Sun Nov 15 23:11:13 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Sun, 15 Nov 2015 18:11:13 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: Your message of "Sun, 15 Nov 2015 17:52:57 EST."
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net> 
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net> 
Message-ID: <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>

In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
 writes:
>WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>                 LSI PCI device (1000,59) not supported.

Does mega_sas(7D) also fail to attach to 1000,59?
John
groenveld at acm.org

From wonko at 4amlunch.net  Sun Nov 15 23:24:20 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Sun, 15 Nov 2015 18:24:20 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
Message-ID: <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>


> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> 
> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
> writes:
>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>                LSI PCI device (1000,59) not supported.
> 
> Does mega_sas(7D) also fail to attach to 1000,59?

It doesn?t complain but it also doesn?t work.

and now fault manager is yelling about a PCIE device fault.

So I?ll say no. :)

-brian


From wonko at 4amlunch.net  Mon Nov 16 00:32:43 2015
From: wonko at 4amlunch.net (wonko at 4amlunch.net)
Date: Sun, 15 Nov 2015 19:32:43 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
Message-ID: <9B5DF05A-5ADF-4218-9B9A-264BDB21A8A9@4amlunch.net>

What I really need to do is find a cheap 9201-16i and stop screwing with the crappy 1068e.

Does anyone know if someone like HP has a rebranded version? Those tend to be cheaper.

-brian

> On Nov 15, 2015, at 18:11, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> 
> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
> writes:
>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>                LSI PCI device (1000,59) not supported.
> 
> Does mega_sas(7D) also fail to attach to 1000,59?
> John
> groenveld at acm.org

From mark0x01 at gmail.com  Mon Nov 16 07:43:20 2015
From: mark0x01 at gmail.com (Mark)
Date: Mon, 16 Nov 2015 20:43:20 +1300
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
 SuperMicro X8DTL-3F
In-Reply-To: <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
Message-ID: <56498918.3040603@gmail.com>

Check the PCI slot's speed setting in setup.
Many older cards need the slot speed lowered to work reliably.

I also seem to recall there may be different LSI firmware that supports 
different sas bus negotiation upper limits that can also cause issues.

Mark.


On 16/11/2015 12:24 p.m., Brian Hechinger wrote:
>
>> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
>>
>> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
>> writes:
>>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>>                 LSI PCI device (1000,59) not supported.
>>
>> Does mega_sas(7D) also fail to attach to 1000,59?
>
> It doesn?t complain but it also doesn?t work.
>
> and now fault manager is yelling about a PCIE device fault.
>
> So I?ll say no. :)
>
> -brian
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>


From danmcd at omniti.com  Mon Nov 16 13:04:53 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 16 Nov 2015 08:04:53 -0500
Subject: [OmniOS-discuss] otherwise stable system sudden crashing
In-Reply-To: <04B0A5C1206D824F8D310C5B3DB28CC9597B93@vEX01.mindstorm-internet.local>
References: <04B0A5C1206D824F8D310C5B3DB28CC9597B93@vEX01.mindstorm-internet.local>
Message-ID: <76B8F59E-3FFF-46C9-93F4-2AFDD9B9AD23@omniti.com>

There were some SMB updates in r151016.

There are even BIGGER ones that landed in illumos just after 016 closed, so I don't have a handy reference from upstream.

Looking at '016, your problem is likely in a function whose frame isn't in your dump:  smb_sign_begin().  There are two potential bcopy() calls there, and one of them is calling with a NULL pointer.

        bcopy(token->tkn_session_key, sign->mackey, SSN_KEY_LEN);
        if (sinfo->ssi_cspwlen > 0) {
                bcopy(sinfo->ssi_cspwd, sign->mackey + SSN_KEY_LEN,
                    sinfo->ssi_cspwlen);
        }

I'm not sure which of those two gets called.

Having said that, I'm not sure how much help I can get or give you without an actual coredump to inspect.

Dan


From wonko at 4amlunch.net  Mon Nov 16 13:05:02 2015
From: wonko at 4amlunch.net (wonko at 4amlunch.net)
Date: Mon, 16 Nov 2015 08:05:02 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <56498918.3040603@gmail.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
Message-ID: <A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>

This is built into the motherboard. This isn't an add on card.

As far as I know (and let's be honest about how much I know here) this is a pretty vanilla firmware. It's the SuperMicro provided one.

-brian

> On Nov 16, 2015, at 02:43, Mark <mark0x01 at gmail.com> wrote:
> 
> Check the PCI slot's speed setting in setup.
> Many older cards need the slot speed lowered to work reliably.
> 
> I also seem to recall there may be different LSI firmware that supports different sas bus negotiation upper limits that can also cause issues.
> 
> Mark.
> 
> 
>> On 16/11/2015 12:24 p.m., Brian Hechinger wrote:
>> 
>>> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
>>> 
>>> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
>>> writes:
>>>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>>>                LSI PCI device (1000,59) not supported.
>>> 
>>> Does mega_sas(7D) also fail to attach to 1000,59?
>> 
>> It doesn?t complain but it also doesn?t work.
>> 
>> and now fault manager is yelling about a PCIE device fault.
>> 
>> So I?ll say no. :)
>> 
>> -brian
>> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From info at houseofancients.nl  Mon Nov 16 13:10:23 2015
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Mon, 16 Nov 2015 13:10:23 +0000
Subject: [OmniOS-discuss] otherwise stable system sudden crashing
In-Reply-To: <76B8F59E-3FFF-46C9-93F4-2AFDD9B9AD23@omniti.com>
References: <04B0A5C1206D824F8D310C5B3DB28CC9597B93@vEX01.mindstorm-internet.local>
	<76B8F59E-3FFF-46C9-93F4-2AFDD9B9AD23@omniti.com>
Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC959835D@vEX01.mindstorm-internet.local>

Hi Dan,

Just tell me were to upload it :-)

Funny thing is, this was happening by just connecting to a share, not even browsing or putting file activity on it

Kr,

Floris

-----Oorspronkelijk bericht-----
Van: Dan McDonald [mailto:danmcd at omniti.com] 
Verzonden: maandag 16 november 2015 14:05
Aan: Floris van Essen ..:: House of Ancients Amstafs ::.. <info at houseofancients.nl>
CC: OmniOS-discuss (omnios-discuss at lists.omniti.com) <omnios-discuss at lists.omniti.com>; Dan McDonald <danmcd at omniti.com>
Onderwerp: Re: [OmniOS-discuss] otherwise stable system sudden crashing

There were some SMB updates in r151016.

There are even BIGGER ones that landed in illumos just after 016 closed, so I don't have a handy reference from upstream.

Looking at '016, your problem is likely in a function whose frame isn't in your dump:  smb_sign_begin().  There are two potential bcopy() calls there, and one of them is calling with a NULL pointer.

        bcopy(token->tkn_session_key, sign->mackey, SSN_KEY_LEN);
        if (sinfo->ssi_cspwlen > 0) {
                bcopy(sinfo->ssi_cspwd, sign->mackey + SSN_KEY_LEN,
                    sinfo->ssi_cspwlen);
        }

I'm not sure which of those two gets called.

Having said that, I'm not sure how much help I can get or give you without an actual coredump to inspect.

Dan

...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl

From cks at cs.toronto.edu  Mon Nov 16 20:17:30 2015
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Mon, 16 Nov 2015 15:17:30 -0500
Subject: [OmniOS-discuss] A small gotcha with switching the ssh & openssh
	packages in OmniOS
Message-ID: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>

 It's great that Sun SSH can now be more or less transparently swapped
for OpenSSH. As part of that both of them provide the SMF service
svc:/network/ssh:default. However, there is a difference in the SMF
properties that each of them uses for boot time ordering: Sun SSH uses
fs-local/*, and OpenSSH uses localfs/*. This means that if you have
customized eg fs-local/entities for Sun SSH (as we have, so that SSH
starts very early), you will probably get odd results if you swap over
to OpenSSH.

 It would be nice if this difference didn't exist and the OpenSSH
package also used fs-local for this SMF dependency. However it may
be too late to change it now.

	- cks, who may not be explaining this clearly or using the
	       right SMF terminology

From danmcd at omniti.com  Mon Nov 16 22:15:10 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 16 Nov 2015 17:15:10 -0500
Subject: [OmniOS-discuss] A small gotcha with switching the ssh &
	openssh packages in OmniOS
In-Reply-To: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
Message-ID: <77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>

TL;DR --> I can change these in omnios-build for ISC DHCP and OpenSSH, but will it cause trouble?!?  That'll require some testing & possibly feedback from you all.

> On Nov 16, 2015, at 3:17 PM, Chris Siebenmann <cks at cs.toronto.edu> wrote:

> Sun SSH uses
> fs-local/*, and OpenSSH uses localfs/*. This means that if you have
> customized eg fs-local/entities for Sun SSH (as we have, so that SSH
> starts very early), you will probably get odd results if you swap over
> to OpenSSH.
> 
> It would be nice if this difference didn't exist and the OpenSSH
> package also used fs-local for this SMF dependency. However it may
> be too late to change it now.

I see what you mean.  Here's SunSSH:

-bash-4.3$ svccfg -s network/ssh listprop | grep local
fs-local                                        dependency
fs-local/entities                               fmri     svc:/system/filesystem/local
fs-local/grouping                               astring  require_all
fs-local/restart_on                             astring  none
fs-local/type                                   astring  service
config_data/entities                            fmri     file://localhost/etc/ssh/sshd_config
-bash-4.3$ 


And here's OpenSSH:

danmcd-os(~)[0]% svccfg -s network/ssh listprop | grep local
localfs                                         dependency
localfs/entities                                fmri     svc:/system/filesystem/local:default
localfs/grouping                                astring  require_all
localfs/restart_on                              astring  none
localfs/type                                    astring  service
config-file/entities                            fmri     file://localhost/etc/ssh/sshd_config
danmcd-os(~)[0]% 



And their sources:

bloody(cmd/ssh)[0]% pwd
/data/danmcd/ws/illumos-omnios/usr/src/cmd/ssh
bloody(cmd/ssh)[0]% grep local etc/ssh.xml
        <dependency name='fs-local'
                        value='svc:/system/filesystem/local' />
                    value='file://localhost/etc/ssh/sshd_config' />
bloody(cmd/ssh)[0]% 


bloody(build/openssh)[0]% grep local * | grep -v build.log
ssh.xml:                <dependency name='localfs'  grouping='require_all'
ssh.xml:                        <service_fmri value='svc:/system/filesystem/local:default' />
ssh.xml:                value='file://localhost/etc/ssh/sshd_config' />
bloody(build/openssh)[0]% 


This seems like such a happy-vs-glad mismatch... and it turns out everything that uses this in illumos-* uses fs-local, and omnios-build splits it 2 vs. 2 (the 2nd instance of localfs in ISC DHCP is all on me... sorry!).


Off the top of my head, I can't *IMAGINE* such a change from localfs to fs-local causing headaches in OpenSSH or ISC DHCP, but it'll require some testing.  Also, will such a change into a backport situation (014 & 016) cause more havoc than a major upgrade?

Food for (mostly my) thought, but I appreciate additional feedback.

Dan


From henson at acm.org  Mon Nov 16 23:45:06 2015
From: henson at acm.org (Paul B. Henson)
Date: Mon, 16 Nov 2015 15:45:06 -0800
Subject: [OmniOS-discuss] A small gotcha with switching the ssh
 &	openssh packages in OmniOS
In-Reply-To: <77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
Message-ID: <070601d120c8$d27a3f30$776ebd90$@acm.org>

> From: Dan McDonald
> Sent: Monday, November 16, 2015 2:15 PM
> 
> Off the top of my head, I can't *IMAGINE* such a change from localfs to
fs-
> local causing headaches in OpenSSH or ISC DHCP, but it'll require some
> testing.  Also, will such a change into a backport situation (014 & 016)
cause
> more havoc than a major upgrade?

Not sure about dhcp, but given you couldn't even install openssh on 014
until last week, I can't imagine anyone has become too dependent on the
existing dependencies ;).

BTW, on the topic of openssh gotchas, I noticed that it does not seem to be
compiled with GSSAPI/Kerberos support? Sunssh is, which makes the bundled
openssh not quite a drop in replacement :(.



From mark0x01 at gmail.com  Tue Nov 17 06:41:53 2015
From: mark0x01 at gmail.com (Mark)
Date: Tue, 17 Nov 2015 19:41:53 +1300
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
 SuperMicro X8DTL-3F
In-Reply-To: <A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
Message-ID: <564ACC31.2060707@gmail.com>

I used to work with the Supermicro Servers and used embedded and cards 
with OpenSolaris. The older firmware seems to have evaporated from 
Supermicro's ftp site.

When Supermicro stopped releasing newer versions, I used the matching 
LSI ones without issues.

I'll dig in my archives and see what info I can find.



On 17/11/2015 2:05 a.m., wonko at 4amlunch.net wrote:
> This is built into the motherboard. This isn't an add on card.
>
> As far as I know (and let's be honest about how much I know here) this is a pretty vanilla firmware. It's the SuperMicro provided one.
>
> -brian
>
>> On Nov 16, 2015, at 02:43, Mark <mark0x01 at gmail.com> wrote:
>>
>> Check the PCI slot's speed setting in setup.
>> Many older cards need the slot speed lowered to work reliably.
>>
>> I also seem to recall there may be different LSI firmware that supports different sas bus negotiation upper limits that can also cause issues.
>>
>> Mark.
>>
>>
>>> On 16/11/2015 12:24 p.m., Brian Hechinger wrote:
>>>
>>>> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
>>>>
>>>> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
>>>> writes:
>>>>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>>>>                 LSI PCI device (1000,59) not supported.
>>>>
>>>> Does mega_sas(7D) also fail to attach to 1000,59?
>>>
>>> It doesn?t complain but it also doesn?t work.
>>>
>>> and now fault manager is yelling about a PCIE device fault.
>>>
>>> So I?ll say no. :)
>>>
>>> -brian
>>>
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From wonko at 4amlunch.net  Tue Nov 17 16:59:37 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 11:59:37 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <564ACC31.2060707@gmail.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
Message-ID: <D86D68C5-0A03-45F2-AE6B-0F32982D5549@4amlunch.net>

So I?ve solved this by decommissioning an older server (was planning on that anyway) and stealing the PERC 6i out of it.

That shows up properly (which isn?t surprising, the machine that was in ran OI for years).

Now to try to figure out how to get the BIOS to want to boot from it.

/me sighs

-brian

> On Nov 17, 2015, at 1:41 AM, Mark <mark0x01 at gmail.com> wrote:
> 
> I used to work with the Supermicro Servers and used embedded and cards with OpenSolaris. The older firmware seems to have evaporated from Supermicro's ftp site.
> 
> When Supermicro stopped releasing newer versions, I used the matching LSI ones without issues.
> 
> I'll dig in my archives and see what info I can find.
> 
> 
> 
> On 17/11/2015 2:05 a.m., wonko at 4amlunch.net wrote:
>> This is built into the motherboard. This isn't an add on card.
>> 
>> As far as I know (and let's be honest about how much I know here) this is a pretty vanilla firmware. It's the SuperMicro provided one.
>> 
>> -brian
>> 
>>> On Nov 16, 2015, at 02:43, Mark <mark0x01 at gmail.com> wrote:
>>> 
>>> Check the PCI slot's speed setting in setup.
>>> Many older cards need the slot speed lowered to work reliably.
>>> 
>>> I also seem to recall there may be different LSI firmware that supports different sas bus negotiation upper limits that can also cause issues.
>>> 
>>> Mark.
>>> 
>>> 
>>>> On 16/11/2015 12:24 p.m., Brian Hechinger wrote:
>>>> 
>>>>> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
>>>>> 
>>>>> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
>>>>> writes:
>>>>>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>>>>>                LSI PCI device (1000,59) not supported.
>>>>> 
>>>>> Does mega_sas(7D) also fail to attach to 1000,59?
>>>> 
>>>> It doesn?t complain but it also doesn?t work.
>>>> 
>>>> and now fault manager is yelling about a PCIE device fault.
>>>> 
>>>> So I?ll say no. :)
>>>> 
>>>> -brian
>>>> 
>>>> _______________________________________________
>>>> OmniOS-discuss mailing list
>>>> OmniOS-discuss at lists.omniti.com
>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>> 
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 


From wonko at 4amlunch.net  Tue Nov 17 17:34:44 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 12:34:44 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <D86D68C5-0A03-45F2-AE6B-0F32982D5549@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<D86D68C5-0A03-45F2-AE6B-0F32982D5549@4amlunch.net>
Message-ID: <7C27FBD7-B579-4237-9E5D-AB52E08DDD15@4amlunch.net>

AH HA!

Lame BIOS.

There are only 6 ?slots? in the boot device selection drop down.

Pulled the two SATA disks hanging off of the ACHI ports and the PERC showed up in the list.

-brian

> On Nov 17, 2015, at 11:59 AM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> So I?ve solved this by decommissioning an older server (was planning on that anyway) and stealing the PERC 6i out of it.
> 
> That shows up properly (which isn?t surprising, the machine that was in ran OI for years).
> 
> Now to try to figure out how to get the BIOS to want to boot from it.
> 
> /me sighs
> 
> -brian
> 
>> On Nov 17, 2015, at 1:41 AM, Mark <mark0x01 at gmail.com> wrote:
>> 
>> I used to work with the Supermicro Servers and used embedded and cards with OpenSolaris. The older firmware seems to have evaporated from Supermicro's ftp site.
>> 
>> When Supermicro stopped releasing newer versions, I used the matching LSI ones without issues.
>> 
>> I'll dig in my archives and see what info I can find.
>> 
>> 
>> 
>> On 17/11/2015 2:05 a.m., wonko at 4amlunch.net wrote:
>>> This is built into the motherboard. This isn't an add on card.
>>> 
>>> As far as I know (and let's be honest about how much I know here) this is a pretty vanilla firmware. It's the SuperMicro provided one.
>>> 
>>> -brian
>>> 
>>>> On Nov 16, 2015, at 02:43, Mark <mark0x01 at gmail.com> wrote:
>>>> 
>>>> Check the PCI slot's speed setting in setup.
>>>> Many older cards need the slot speed lowered to work reliably.
>>>> 
>>>> I also seem to recall there may be different LSI firmware that supports different sas bus negotiation upper limits that can also cause issues.
>>>> 
>>>> Mark.
>>>> 
>>>> 
>>>>> On 16/11/2015 12:24 p.m., Brian Hechinger wrote:
>>>>> 
>>>>>> On Nov 15, 2015, at 6:11 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
>>>>>> 
>>>>>> In message <B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC at 4amlunch.net>, Brian Hechinger
>>>>>> writes:
>>>>>>> WARNING: /pci at 0,0/pci8086,340a at 3/pci159d,6 at 0 (mpt0):
>>>>>>>               LSI PCI device (1000,59) not supported.
>>>>>> 
>>>>>> Does mega_sas(7D) also fail to attach to 1000,59?
>>>>> 
>>>>> It doesn?t complain but it also doesn?t work.
>>>>> 
>>>>> and now fault manager is yelling about a PCIE device fault.
>>>>> 
>>>>> So I?ll say no. :)
>>>>> 
>>>>> -brian
>>>>> 
>>>>> _______________________________________________
>>>>> OmniOS-discuss mailing list
>>>>> OmniOS-discuss at lists.omniti.com
>>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>> 
>>>> _______________________________________________
>>>> OmniOS-discuss mailing list
>>>> OmniOS-discuss at lists.omniti.com
>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> 
> 


From jdg117 at elvis.arl.psu.edu  Tue Nov 17 19:22:26 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Tue, 17 Nov 2015 14:22:26 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <564ACC31.2060707@gmail.com> 
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
Message-ID: <201511171922.tAHJMQWX005311@elvis.arl.psu.edu>

In message <564ACC31.2060707 at gmail.com>, Mark writes:
>I used to work with the Supermicro Servers and used embedded and cards 
>with OpenSolaris. The older firmware seems to have evaporated from 
>Supermicro's ftp site.
>
>When Supermicro stopped releasing newer versions, I used the matching 
>LSI ones without issues.

Avago has broken many of the LSI links but I found a newer
version of the old sasflash.exe for DOS.

But Brian's instincts are probably right and he's best off 
buying a lightly used LSI SAS 6Gb HBA off eBay and
flashing to the IT firmware.

John
groenveld at acm.org



From wonko at 4amlunch.net  Tue Nov 17 19:38:39 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 14:38:39 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
Message-ID: <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>

Yeah, the onboard 1068 (and now the PERC 6i) are just a stopgap until I get a proper HBA (hopefully a cheap 9201-16i)

Now to get the NVMe drives recognized. :)

-brian

> On Nov 17, 2015, at 2:22 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> 
> In message <564ACC31.2060707 at gmail.com>, Mark writes:
>> I used to work with the Supermicro Servers and used embedded and cards 
>> with OpenSolaris. The older firmware seems to have evaporated from 
>> Supermicro's ftp site.
>> 
>> When Supermicro stopped releasing newer versions, I used the matching 
>> LSI ones without issues.
> 
> Avago has broken many of the LSI links but I found a newer
> version of the old sasflash.exe for DOS.
> 
> But Brian's instincts are probably right and he's best off 
> buying a lightly used LSI SAS 6Gb HBA off eBay and
> flashing to the IT firmware.
> 
> John
> groenveld at acm.org
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From danmcd at omniti.com  Tue Nov 17 19:45:15 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 17 Nov 2015 14:45:15 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
Message-ID: <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>


> On Nov 17, 2015, at 2:38 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> Now to get the NVMe drives recognized. :)

The installer is not going to find 'em until at least this:

	https://illumos.org/issues/6232

gets fixed.

OTOH, Kayak should see them, as should installed 014 and beyond.

Dan


From wonko at 4amlunch.net  Tue Nov 17 19:57:28 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 14:57:28 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
Message-ID: <E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>

Installed r151016, but?

root at basket1:/root# prtconf -d | grep Samsung
            pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)
            pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)

-brian

> On Nov 17, 2015, at 2:45 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Nov 17, 2015, at 2:38 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>> 
>> Now to get the NVMe drives recognized. :)
> 
> The installer is not going to find 'em until at least this:
> 
> 	https://illumos.org/issues/6232
> 
> gets fixed.
> 
> OTOH, Kayak should see them, as should installed 014 and beyond.
> 
> Dan
> 


From protonwrangler at gmail.com  Tue Nov 17 20:03:04 2015
From: protonwrangler at gmail.com (Warren Marts)
Date: Tue, 17 Nov 2015 13:03:04 -0700
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
Message-ID: <CAN8fiVvT5-B7dDoAvb_EFFu7=-hrg=V7RUWjOKiKK7B3UURXnA@mail.gmail.com>

I ran into an issue with an X10 (current generation) Supermicro board that
would not flash an LSI card from a DOS boot environment, but only from the
UEFI shell with sas2flash.efi - Not at all sure when they got the EFI
bioses.

On Tue, Nov 17, 2015 at 12:45 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Nov 17, 2015, at 2:38 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> >
> > Now to get the NVMe drives recognized. :)
>
> The installer is not going to find 'em until at least this:
>
>         https://illumos.org/issues/6232
>
> gets fixed.
>
> OTOH, Kayak should see them, as should installed 014 and beyond.
>
> 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/20151117/bb7c0ab6/attachment.html>

From danmcd at omniti.com  Tue Nov 17 20:14:49 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 17 Nov 2015 15:14:49 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
Message-ID: <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>


> On Nov 17, 2015, at 2:57 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> Installed r151016, but?
> 
> root at basket1:/root# prtconf -d | grep Samsung
>            pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)
>            pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)

Please share "prtconf -v"?  Also...

	https://pci-ids.ucw.cz/read/PC/144d/a800

I have no idea if this is an NVMe or not.  The "prtconf -v" will show aliases, which may or may not provide more information.

I wonder if it's beyond NVMe 1.0?  Perhaps...

Also, I wonder if a PCI Class entry needs to land in /etc/driver_aliases?  I found this:

	https://lists.debian.org/debian-boot/2015/09/msg00167.html

Suggesting that MAYBE we need this in /etc/driver_aliases:

	nvme "pciclass,010802" 

You should mention this on the illumos developer list.  You also COULD put that entry in by hand, reboot, and see THEN if it pops up as a device?

Dan


From wonko at 4amlunch.net  Tue Nov 17 20:23:23 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 15:23:23 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
Message-ID: <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>

prtconf output:

https://gist.github.com/bhechinger/01ba826eb8e0415e4530 <https://gist.github.com/bhechinger/01ba826eb8e0415e4530>

I trimmed this to just the relevant entry for the Samsung drive

The exact card is this:

http://www.amazon.com/gp/product/B00VK0XMPE <http://www.amazon.com/gp/product/B00VK0XMPE>

I?m willing to try anything. I?ll let you know how it goes. :)

-brian

> On Nov 17, 2015, at 3:14 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Nov 17, 2015, at 2:57 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>> 
>> Installed r151016, but?
>> 
>> root at basket1:/root# prtconf -d | grep Samsung
>>           pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)
>>           pci144d,a801 (pciex144d,a802) [Samsung Electronics Co Ltd unknown device] (driver not attached)
> 
> Please share "prtconf -v"?  Also...
> 
> 	https://pci-ids.ucw.cz/read/PC/144d/a800
> 
> I have no idea if this is an NVMe or not.  The "prtconf -v" will show aliases, which may or may not provide more information.
> 
> I wonder if it's beyond NVMe 1.0?  Perhaps...
> 
> Also, I wonder if a PCI Class entry needs to land in /etc/driver_aliases?  I found this:
> 
> 	https://lists.debian.org/debian-boot/2015/09/msg00167.html
> 
> Suggesting that MAYBE we need this in /etc/driver_aliases:
> 
> 	nvme "pciclass,010802" 
> 
> You should mention this on the illumos developer list.  You also COULD put that entry in by hand, reboot, and see THEN if it pops up as a device?
> 
> Dan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151117/e32d066d/attachment.html>

From danmcd at omniti.com  Tue Nov 17 20:53:07 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 17 Nov 2015 15:53:07 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
	<07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
Message-ID: <D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>


> On Nov 17, 2015, at 3:23 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> prtconf output:
> 
> https://gist.github.com/bhechinger/01ba826eb8e0415e4530
> 
> I trimmed this to just the relevant entry for the Samsung drive

Thank you.  Yes, there's no reference to the single NVMe entry that exists today:

bloody(~/ws/illumos-omnios)[0]% grep nvme /etc/driver_aliases
nvme "pciex8086,953"
bloody(~/ws/illumos-omnios)[0]% 

But that PCIe-class is worth a shot.

> I?m willing to try anything. I?ll let you know how it goes. :)

If using pciclass works, it's potentially a worthy addition to illumos-gate upstream.  It appears the code doesn't check for the specific 8086,953 ID mentioned above, so there's a better chance it'll work.

You REALLY need to bring this up on the illumos developer's list, and if you can't, I can.  ESPECIALLY if it works.

Thanks,
Dan


From wonko at 4amlunch.net  Tue Nov 17 21:28:49 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 16:28:49 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
	<07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
	<D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>
Message-ID: <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>


> On Nov 17, 2015, at 3:53 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Nov 17, 2015, at 3:23 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>> 
>> prtconf output:
>> 
>> https://gist.github.com/bhechinger/01ba826eb8e0415e4530
>> 
>> I trimmed this to just the relevant entry for the Samsung drive
> 
> Thank you.  Yes, there's no reference to the single NVMe entry that exists today:
> 
> bloody(~/ws/illumos-omnios)[0]% grep nvme /etc/driver_aliases
> nvme "pciex8086,953"
> bloody(~/ws/illumos-omnios)[0]% 
> 
> But that PCIe-class is worth a shot.
> 
>> I?m willing to try anything. I?ll let you know how it goes. :)
> 
> If using pciclass works, it's potentially a worthy addition to illumos-gate upstream.  It appears the code doesn't check for the specific 8086,953 ID mentioned above, so there's a better chance it'll work.
> 
> You REALLY need to bring this up on the illumos developer's list, and if you can't, I can.  ESPECIALLY if it works.

I tried adding the pciclass and that had no effect.

I?ll take this up with the illumos list, thanks!

-brian

From danmcd at omniti.com  Tue Nov 17 21:29:46 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 17 Nov 2015 16:29:46 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
	<07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
	<D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>
	<7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>
Message-ID: <3878828F-A0D4-41E7-BD08-175CC7593E1B@omniti.com>


> On Nov 17, 2015, at 4:28 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
> I?ll take this up with the illumos list, thanks!

Check your /var/adm/messages before doing so.  Maybe nvme-the-driver complained about something?  (I'd guess NVMe version is beyond 1.0...)

Dan


From wonko at 4amlunch.net  Wed Nov 18 02:19:14 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 21:19:14 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <3878828F-A0D4-41E7-BD08-175CC7593E1B@omniti.com>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
	<07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
	<D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>
	<7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>
	<3878828F-A0D4-41E7-BD08-175CC7593E1B@omniti.com>
Message-ID: <D77F1921-6FAF-48CA-B91A-64E32314E92F@4amlunch.net>

The only thing in that log matching NVMe is a number of these in quick succession:

Nov 17 13:00:25 basket1 genunix: [ID 819705 kern.notice] /kernel/drv/amd64/nvme: undefined symbol
Nov 17 13:00:25 basket1 genunix: [ID 472681 kern.notice] WARNING: mod_load: cannot load module ?nvme'

-brian

> On Nov 17, 2015, at 4:29 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Nov 17, 2015, at 4:28 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>> 
>> I?ll take this up with the illumos list, thanks!
> 
> Check your /var/adm/messages before doing so.  Maybe nvme-the-driver complained about something?  (I'd guess NVMe version is beyond 1.0...)
> 
> Dan
> 


From wonko at 4amlunch.net  Wed Nov 18 04:18:11 2015
From: wonko at 4amlunch.net (Brian Hechinger)
Date: Tue, 17 Nov 2015 23:18:11 -0500
Subject: [OmniOS-discuss] Can't get OmniOS to see LSI 1068e on
	SuperMicro X8DTL-3F
In-Reply-To: <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>
References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net>
	<201511152216.tAFMG59o016126@elvis.arl.psu.edu>
	<B888B845-43EB-4E5C-BDC8-EEB0B2F8C2EC@4amlunch.net>
	<201511152311.tAFNBDrJ017137@elvis.arl.psu.edu>
	<2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net>
	<56498918.3040603@gmail.com>
	<A1904E6B-9FDB-4ECA-8A96-552752CE25CF@4amlunch.net>
	<564ACC31.2060707@gmail.com>
	<201511171922.tAHJMQWX005311@elvis.arl.psu.edu>
	<9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net>
	<5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com>
	<E5190CFC-E835-4A96-A21F-8DDF2E63AFDC@4amlunch.net>
	<7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com>
	<07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net>
	<D5BE0EBC-1AAE-4C64-85D1-06DF265C62B9@omniti.com>
	<7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net>
Message-ID: <D9D28357-9340-43CA-AD58-5B04043D1A54@4amlunch.net>


> On Nov 17, 2015, at 4:28 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
> 
>> 
>> On Nov 17, 2015, at 3:53 PM, Dan McDonald <danmcd at omniti.com> wrote:
>> 
>> 
>>> On Nov 17, 2015, at 3:23 PM, Brian Hechinger <wonko at 4amlunch.net> wrote:
>>> 
>>> prtconf output:
>>> 
>>> https://gist.github.com/bhechinger/01ba826eb8e0415e4530
>>> 
>>> I trimmed this to just the relevant entry for the Samsung drive
>> 
>> Thank you.  Yes, there's no reference to the single NVMe entry that exists today:
>> 
>> bloody(~/ws/illumos-omnios)[0]% grep nvme /etc/driver_aliases
>> nvme "pciex8086,953"
>> bloody(~/ws/illumos-omnios)[0]% 
>> 
>> But that PCIe-class is worth a shot.
>> 
>>> I?m willing to try anything. I?ll let you know how it goes. :)
>> 
>> If using pciclass works, it's potentially a worthy addition to illumos-gate upstream.  It appears the code doesn't check for the specific 8086,953 ID mentioned above, so there's a better chance it'll work.
>> 
>> You REALLY need to bring this up on the illumos developer's list, and if you can't, I can.  ESPECIALLY if it works.
> 
> I tried adding the pciclass and that had no effect.

A quick update here. Adding this causes the thing to kernel panic every time it tries to load the name drivers and talk to these drives. :(

-brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151117/c74261d7/attachment.html>

From al.slater at scluk.com  Wed Nov 18 17:45:13 2015
From: al.slater at scluk.com (Al Slater)
Date: Wed, 18 Nov 2015 17:45:13 +0000
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
Message-ID: <564CB929.7010308@scluk.com>

On 13/11/15 20:13, Dan McDonald wrote:
> 014:
> ------
> 
<snip>
>
> - ilbd memory leak plug

Thanks for getting this is there Dan, we have been running leak free for
3 days now.

-- 
Al Slater


From mir at miras.org  Wed Nov 18 17:51:47 2015
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 18 Nov 2015 18:51:47 +0100
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <564CB929.7010308@scluk.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
	<564CB929.7010308@scluk.com>
Message-ID: <20151118185147.4b98425c@sleipner.datanom.net>

Hi Dan,

On Wed, 18 Nov 2015 17:45:13 +0000
Al Slater <al.slater at scluk.com> wrote:

> > - ilbd memory leak plug  
> 
> Thanks for getting this is there Dan, we have been running leak free for
> 3 days now.
> 
Will there be an official update to r151014 containing this patch?

-- 
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:
This fortune is dedicated to your mother, without whose invaluable
assistance last night would never have been possible.
-------------- 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/20151118/880ec9a2/attachment.bin>

From danmcd at omniti.com  Wed Nov 18 18:26:26 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 18 Nov 2015 13:26:26 -0500
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <20151118185147.4b98425c@sleipner.datanom.net>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
	<564CB929.7010308@scluk.com>
	<20151118185147.4b98425c@sleipner.datanom.net>
Message-ID: <7D9A1224-A8A5-4DA4-9C27-E55A68C432B2@omniti.com>

Didn't you read?  It's in there too:

http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014

Dan 

Sent from my iPhone (typos, autocorrect, and all)

> On Nov 18, 2015, at 12:51 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> Hi Dan,
> 
> On Wed, 18 Nov 2015 17:45:13 +0000
> Al Slater <al.slater at scluk.com> wrote:
> 
>>> - ilbd memory leak plug  
>> 
>> Thanks for getting this is there Dan, we have been running leak free for
>> 3 days now.
> Will there be an official update to r151014 containing this patch?
> 
> -- 
> 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:
> This fortune is dedicated to your mother, without whose invaluable
> assistance last night would never have been possible.
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From mir at miras.org  Wed Nov 18 19:15:04 2015
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 18 Nov 2015 20:15:04 +0100
Subject: [OmniOS-discuss] Updates for OmniOS r151014 & r151016
In-Reply-To: <7D9A1224-A8A5-4DA4-9C27-E55A68C432B2@omniti.com>
References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com>
	<C9ACA200-07AF-4CA1-9E44-5F9F1C837D3B@omniti.com>
	<564CB929.7010308@scluk.com>
	<20151118185147.4b98425c@sleipner.datanom.net>
	<7D9A1224-A8A5-4DA4-9C27-E55A68C432B2@omniti.com>
Message-ID: <20151118201504.4c413010@sleipner.datanom.net>

On Wed, 18 Nov 2015 13:26:26 -0500
Dan McDonald <danmcd at omniti.com> wrote:

> Didn't you read?  It's in there too:
> 
> http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014
> 
Sorry, I thought that was another issue since OP has just run tests for
3 days.

-- 
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:
A certain amount of opposition is a help, not a hindrance. Kites rise
against the wind, not with it.
-------------- 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/20151118/c40fa2ce/attachment.bin>

From geoffn at gnaa.net  Wed Nov 18 20:05:29 2015
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 18 Nov 2015 12:05:29 -0800
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
In-Reply-To: <416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
References: <5646475F.9010608@gnaa.net>
	<416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
Message-ID: <564CDA09.3010505@gnaa.net>

On 15-11-13 12:36 PM, Dan McDonald wrote:
>> On Nov 13, 2015, at 3:26 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>
>> Hi.
>>
>> I am migrating a couple of machines from OI to OmniOS.
>>
>> Is it possible to install omnios into a new boot environment so I can keep both the install of OI and then boot between them?
> Wow.  I don't know.  It's *theoretically possible* but I think you'd have to install OmniOS on a VM, zfs snapshot-and-send the rpool/ROOT/<be> to the OI box, and manually construct an OmniOS BE around that received ZFS snapshot, including adding GRUB entries.
>
> Haven't tried it myself.
>
> Dan
>

Thanks Dan, I will do some testing to see how it works.

Geoff

From dan at syneto.eu  Wed Nov 18 20:47:19 2015
From: dan at syneto.eu (Dan Vatca)
Date: Wed, 18 Nov 2015 22:47:19 +0200
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
In-Reply-To: <564CDA09.3010505@gnaa.net>
References: <5646475F.9010608@gnaa.net>
	<416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
	<564CDA09.3010505@gnaa.net>
Message-ID: <CAELW+FdxStxWOWv6vONSytw8yxLZQa6duA+2i-w=phe8NoNG6A@mail.gmail.com>

Hi Geoff,

This is what I did (in broad strokes):
1. create a new boot environment (beadm create)
2. receive the @initial snapshot of an OmniOS install over the created
dataset
3. copy over some configuration files from /etc to the new boot environment
4. boot the new copy

It is not actually an upgrade, as an IPS based upgrade is not possible due
to the way OmniOS versions packages.
This is the closest you can get, and will have some advantages over
installing a fresh one:
1. will keep your old install, so you can go back if anything fails
2. in terms of downtime, it will be equivalent to an upgrade, as you won't
be down during a fresh install (if all you need is the IP configuration and
the data pool(s) imported) ...
This is not perfect, as you will have trouble finding an easy way to bring
over your STMF configuration, and some other things kept in "binary" form
from the OI root.




Dan V?tca

CTO at Syneto

Tel: +40723604357, Skype: dan_vatca

<http://www.syneto.net/>

On Wed, Nov 18, 2015 at 10:05 PM, Geoff Nordli <geoffn at gnaa.net> wrote:

> On 15-11-13 12:36 PM, Dan McDonald wrote:
>
>> On Nov 13, 2015, at 3:26 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>>>
>>> Hi.
>>>
>>> I am migrating a couple of machines from OI to OmniOS.
>>>
>>> Is it possible to install omnios into a new boot environment so I can
>>> keep both the install of OI and then boot between them?
>>>
>> Wow.  I don't know.  It's *theoretically possible* but I think you'd have
>> to install OmniOS on a VM, zfs snapshot-and-send the rpool/ROOT/<be> to the
>> OI box, and manually construct an OmniOS BE around that received ZFS
>> snapshot, including adding GRUB entries.
>>
>> Haven't tried it myself.
>>
>> Dan
>>
>>
> Thanks Dan, I will do some testing to see how it works.
>
> Geoff
>
> _______________________________________________
> 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/20151118/9bfcbced/attachment.html>

From geoffn at gnaa.net  Thu Nov 19 00:04:27 2015
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 18 Nov 2015 16:04:27 -0800
Subject: [OmniOS-discuss] install OmniOS into a new boot environment
In-Reply-To: <CAELW+FdxStxWOWv6vONSytw8yxLZQa6duA+2i-w=phe8NoNG6A@mail.gmail.com>
References: <5646475F.9010608@gnaa.net>
	<416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com>
	<564CDA09.3010505@gnaa.net>
	<CAELW+FdxStxWOWv6vONSytw8yxLZQa6duA+2i-w=phe8NoNG6A@mail.gmail.com>
Message-ID: <564D120B.3050409@gnaa.net>


Hi Dan V.

Great idea on the creating a new BE and receiving the snapshot into it.

Being able to keep the original configuration so I can "revert" in the 
event of an issue is important.

Any of the smf services I can just export out and import in the BE.

thanks!!

Geoff

On 15-11-18 12:47 PM, Dan Vatca wrote:
> Hi Geoff,
>
> This is what I did (in broad strokes):
> 1. create a new boot environment (beadm create)
> 2. receive the @initial snapshot of an OmniOS install over the created 
> dataset
> 3. copy over some configuration files from /etc to the new boot 
> environment
> 4. boot the new copy
>
> It is not actually an upgrade, as an IPS based upgrade is not possible 
> due to the way OmniOS versions packages.
> This is the closest you can get, and will have some advantages over 
> installing a fresh one:
> 1. will keep your old install, so you can go back if anything fails
> 2. in terms of downtime, it will be equivalent to an upgrade, as you 
> won't be down during a fresh install (if all you need is the IP 
> configuration and the data pool(s) imported) ...
> This is not perfect, as you will have trouble finding an easy way to 
> bring over your STMF configuration, and some other things kept in 
> "binary" form from the OI root.
>
>
>
>
> Dan V?tca
>
> CTO at Syneto
>
> Tel: +40723604357, Skype: dan_vatca
>
> <http://www.syneto.net/>
>
>
> On Wed, Nov 18, 2015 at 10:05 PM, Geoff Nordli <geoffn at gnaa.net 
> <mailto:geoffn at gnaa.net>> wrote:
>
>     On 15-11-13 12:36 PM, Dan McDonald wrote:
>
>             On Nov 13, 2015, at 3:26 PM, Geoff Nordli <geoffn at gnaa.net
>             <mailto:geoffn at gnaa.net>> wrote:
>
>             Hi.
>
>             I am migrating a couple of machines from OI to OmniOS.
>
>             Is it possible to install omnios into a new boot
>             environment so I can keep both the install of OI and then
>             boot between them?
>
>         Wow.  I don't know.  It's *theoretically possible* but I think
>         you'd have to install OmniOS on a VM, zfs snapshot-and-send
>         the rpool/ROOT/<be> to the OI box, and manually construct an
>         OmniOS BE around that received ZFS snapshot, including adding
>         GRUB entries.
>
>         Haven't tried it myself.
>
>         Dan
>
>
>     Thanks Dan, I will do some testing to see how it works.
>
>     Geoff
>
>     _______________________________________________
>     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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151118/5dbc9530/attachment.html>

From danmcd at omniti.com  Thu Nov 19 14:16:09 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 19 Nov 2015 09:16:09 -0500
Subject: [OmniOS-discuss] A small gotcha with switching the ssh
	&	openssh packages in OmniOS
In-Reply-To: <070601d120c8$d27a3f30$776ebd90$@acm.org>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
	<070601d120c8$d27a3f30$776ebd90$@acm.org>
Message-ID: <136CF4A4-0281-4676-BD87-A5D85B0A8241@omniti.com>


> On Nov 16, 2015, at 6:45 PM, Paul B. Henson <henson at acm.org> wrote:
> 
> BTW, on the topic of openssh gotchas, I noticed that it does not seem to be
> compiled with GSSAPI/Kerberos support? Sunssh is, which makes the bundled
> openssh not quite a drop in replacement :(.

This is going to sound silly, but do you have:

	UsePAM yes

in /etc/ssh/sshd_config ?

I have reports that "fixes krb5 for me at least" from one of our community members.

Dan


From mir at miras.org  Thu Nov 19 18:22:26 2015
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 19 Nov 2015 19:22:26 +0100
Subject: [OmniOS-discuss] mixing 512B and 4K disks in vdev
Message-ID: <20151119192226.1f494d2e@sleipner.datanom.net>

Hi all,

I have to replace a HDD disk in a mirrored vdev which is using ashift=9.
The problem is that all new HDD's is 4K disks so I wonder if anyone has
made some performance measurements of using a 4K disk with ashift=9 in
contrast to the obvious ashift=12?

As I understand it you cannot detach a vdev from a pool so it is not
possible to replace both disks with 4K disks. How do you handle a
situation like this? 

-- 
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:
"It doesn't much signify whom one marries for one is sure to find out
next morning it was someone else."
		-- Rogers
-------------- 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/20151119/afea78c0/attachment.bin>

From johan.kragsterman at capvert.se  Thu Nov 19 18:44:23 2015
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Thu, 19 Nov 2015 19:44:23 +0100
Subject: [OmniOS-discuss] Ang:  mixing 512B and 4K disks in vdev
In-Reply-To: <20151119192226.1f494d2e@sleipner.datanom.net>
References: <20151119192226.1f494d2e@sleipner.datanom.net>
Message-ID: <OF0A818797.B17F7412-ONC1257F02.0066F103-C1257F02.0066F105@inse.com>


Hi!

-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: omnios-discuss <omnios-discuss at lists.omniti.com>
Fr?n: Michael Rasmussen 
S?nt av: "OmniOS-discuss" 
Datum: 2015-11-19 19:24
?rende: [OmniOS-discuss] mixing 512B and 4K disks in vdev

Hi all,

I have to replace a HDD disk in a mirrored vdev which is using ashift=9.
The problem is that all new HDD's is 4K disks so I wonder if anyone has
made some performance measurements of using a 4K disk with ashift=9 in
contrast to the obvious ashift=12?

As I understand it you cannot detach a vdev from a pool so it is not
possible to replace both disks with 4K disks. How do you handle a
situation like this? 





You could attach the first one, and when it resilvered, you can detach the other one, to be able to have the same drives in that particular vdev.

And in the same way, you can swap the rest of the vdevs as well, if you would like to change all drives to 4k.

Rgrds Johan





-- 
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:
"It doesn't much signify whom one marries for one is sure to find out
next morning it was someone else."
-- Rogers
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


[bilagan "att49p45.dat" borttagen av Johan Kragsterman/Capvert]


From cks at cs.toronto.edu  Thu Nov 19 18:55:50 2015
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Thu, 19 Nov 2015 13:55:50 -0500
Subject: [OmniOS-discuss] mixing 512B and 4K disks in vdev
Message-ID: <20151119185550.4B5CB7A05FD@apps0.cs.toronto.edu>

> I have to replace a HDD disk in a mirrored vdev which is using
> ashift=9.  The problem is that all new HDD's is 4K disks so I wonder
> if anyone has made some performance measurements of using a 4K disk
> with ashift=9 in contrast to the obvious ashift=12?
>
> As I understand it you cannot detach a vdev from a pool so it is not
> possible to replace both disks with 4K disks. How do you handle a
> situation like this?

 OmniOS will not normally allow you to add a 4k disk to a vdev with
ashift=9, regardless of any performance impact. As far as I know, in
order to get around this you must modify /kernel/drv/sd.conf in order
to lie about the disk's physical sector size, per:

    http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+Format+disks

Note that running 4k disks as 512-byte disks is ever so slightly risky,
because it converts what ZFS thinks are atomic writes of a sector into
read-modify-writes that affect some surrounding sectors.

 If you can't run 4k disks this way (or don't want to), as far as I know
your only option is to create an entire new pool with new vdevs that are
all ashift=12.

(This is where I really wish that all new vdevs were created with
ashift=12 as the default and you had to explicitly override it to get
ashift=9 vdevs, even on 512b drives. Creating ashift=9 vdevs is simply
not future proof at this point, and hasn't been for several years.)

	- cks

From mir at miras.org  Thu Nov 19 19:30:35 2015
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 19 Nov 2015 20:30:35 +0100
Subject: [OmniOS-discuss] Ang:  mixing 512B and 4K disks in vdev
In-Reply-To: <OF0A818797.B17F7412-ONC1257F02.0066F103-C1257F02.0066F105@inse.com>
References: <20151119192226.1f494d2e@sleipner.datanom.net>
	<OF0A818797.B17F7412-ONC1257F02.0066F103-C1257F02.0066F105@inse.com>
Message-ID: <20151119203035.67a03d68@sleipner.datanom.net>

On Thu, 19 Nov 2015 19:44:23 +0100
Johan Kragsterman <johan.kragsterman at capvert.se> wrote:

> 
> You could attach the first one, and when it resilvered, you can detach the other one, to be able to have the same drives in that particular vdev.
> 
> And in the same way, you can swap the rest of the vdevs as well, if you would like to change all drives to 4k.
> 
This is not possible since ashift is configured at vdev level so
changing ashift for an existing vdev is not possible.

-- 
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 brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to work.
-------------- 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/20151119/5d002b34/attachment.bin>

From mir at miras.org  Thu Nov 19 19:35:05 2015
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 19 Nov 2015 20:35:05 +0100
Subject: [OmniOS-discuss] mixing 512B and 4K disks in vdev
In-Reply-To: <20151119185550.4B5CB7A05FD@apps0.cs.toronto.edu>
References: <20151119185550.4B5CB7A05FD@apps0.cs.toronto.edu>
Message-ID: <20151119203505.3adb8df3@sleipner.datanom.net>

On Thu, 19 Nov 2015 13:55:50 -0500
Chris Siebenmann <cks at cs.toronto.edu> wrote:

> > I have to replace a HDD disk in a mirrored vdev which is using
> > ashift=9.  The problem is that all new HDD's is 4K disks so I wonder
> > if anyone has made some performance measurements of using a 4K disk
> > with ashift=9 in contrast to the obvious ashift=12?
> >
> > As I understand it you cannot detach a vdev from a pool so it is not
> > possible to replace both disks with 4K disks. How do you handle a
> > situation like this?  
> 
>  OmniOS will not normally allow you to add a 4k disk to a vdev with
> ashift=9, regardless of any performance impact. As far as I know, in
> order to get around this you must modify /kernel/drv/sd.conf in order
> to lie about the disk's physical sector size, per:
If the disk is a 512e type this is possible. Meaning 512B is reported
to the kernel and the driver firmware will handle converting to 4K.

> 
>  If you can't run 4k disks this way (or don't want to), as far as I know
> your only option is to create an entire new pool with new vdevs that are
> all ashift=12.
> 
somewhat frustrating that a solution for transitioning a 512B vdev to
4K apart from creating a new pool has not be made.

-- 
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:
Very few profundities can be expressed in less than 80 characters.
-------------- 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/20151119/f0eb7cec/attachment.bin>

From henson at acm.org  Thu Nov 19 20:45:19 2015
From: henson at acm.org (Paul B. Henson)
Date: Thu, 19 Nov 2015 12:45:19 -0800
Subject: [OmniOS-discuss] A small gotcha with switching the
 ssh	&	openssh packages in OmniOS
In-Reply-To: <136CF4A4-0281-4676-BD87-A5D85B0A8241@omniti.com>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
	<070601d120c8$d27a3f30$776ebd90$@acm.org>
	<136CF4A4-0281-4676-BD87-A5D85B0A8241@omniti.com>
Message-ID: <00f501d1230b$34a954e0$9dfbfea0$@acm.org>

> From: Dan McDonald
> Sent: Thursday, November 19, 2015 6:16 AM
> 
> This is going to sound silly, but do you have:
> 
> 	UsePAM yes
> 
> in /etc/ssh/sshd_config ?
> 
> I have reports that "fixes krb5 for me at least" from one of our community
> members.

Using PAM allows openssh to do username/password-based authentication
against a Kerberos realm, but it does not allow actual Kerberos
authentication (ie, ticket based, without passwords). If that's all you
need, there is no requirement for actual Kerberos/GSSAPI support in openssh
itself, but if you want to do real Kerberos (ticket based authentication,
TGT forwarding, etc), you still need it.


From bfriesen at simple.dallas.tx.us  Thu Nov 19 20:58:42 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 19 Nov 2015 14:58:42 -0600 (CST)
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
Message-ID: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>

What is the best way to obtain and install Apache for OmniOS r151016 
which works properly and will survive the regular upgrade process?  I 
am really surprised to not find Apache in the standard OmniOS 
packages.

I spotted "group/feature/amp" but it does not work since the packages 
it depends on do not exist.  I do not want this whole group anyway 
since I have no use for MySQL and PHP.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From waldenvik at gmx.com  Thu Nov 19 21:46:53 2015
From: waldenvik at gmx.com (Martin Waldenvik)
Date: Thu, 19 Nov 2015 22:46:53 +0100
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
Message-ID: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>

Hi Bob

Why not use joyents pkgsrc. Install only apache. 

Regards
Martin

Sent from my iPhone

> On 19 Nov 2015, at 21:58, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> What is the best way to obtain and install Apache for OmniOS r151016 which works properly and will survive the regular upgrade process?  I am really surprised to not find Apache in the standard OmniOS packages.
> 
> I spotted "group/feature/amp" but it does not work since the packages it depends on do not exist.  I do not want this whole group anyway since I have no use for MySQL and PHP.
> 
> 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

From bfriesen at simple.dallas.tx.us  Thu Nov 19 23:02:03 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 19 Nov 2015 17:02:03 -0600 (CST)
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
	<3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
Message-ID: <alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>

On Thu, 19 Nov 2015, Martin Waldenvik wrote:

> Hi Bob
>
> Why not use joyents pkgsrc. Install only apache.

I did this by accident before when I selected to install 'subversion' 
(to get a client) and was surprised to see it install Apache.  At the 
time I thought that it might conflict with some Apache offered by 
OmniOS.

Pksrc is indeed quite a lot of packages.  It is a different package 
dependency system than IPS so it is possible to create 
excessive/conflicting installs since there is some overlap.

Another possibility is to create one's own IPS repository with 
packages built from source code (e.g. SFE pkgbuild 
https://sourceforge.net/projects/pkgbuild/) and published as described 
at the bottom of http://omnios.omniti.com/wiki.php/Packaging.  This 
requires more work, but could benefit the community.

The various SFE package collections I see targeting OmniOS are small.

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  Thu Nov 19 23:23:41 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Thu, 19 Nov 2015 18:23:41 -0500
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: Your message of "Thu, 19 Nov 2015 14:58:42 CST."
	<alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org> 
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org> 
Message-ID: <201511192323.tAJNNftY029365@elvis.arl.psu.edu>

In message <alpine.GSO.2.01.1511191451530.1673 at freddy.simplesystems.org>, Bob F
riesenhahn writes:
>What is the best way to obtain and install Apache for OmniOS r151016 
>which works properly and will survive the regular upgrade process?  I 

#! /bin/sh
#
# Created by configure

CC="gcc"; export CC
CFLAGS="-m64 -O3"; export CFLAGS
LDFLAGS="-m64"; export LDFLAGS
"./configure" \
"--with-expat=/usr" \
"--with-ssl=/usr" \
"--enable-ssl" \
"--enable-proxy" \
"--enable-rewrite" \
"--enable-modules=all" \
"--enable-mods-shared=all" \
"--with-included-apr" \
"--prefix=/opt/apache2" \
"CC=gcc" \
"CFLAGS=-m64 -O3" \
"LDFLAGS=-m64"

Best for me, but YMMV.

>am really surprised to not find Apache in the standard OmniOS 
>packages.

<URL:http://omnios.omniti.com/wiki.php/KYSTY>

John
groenveld at acm.org

From tom-omnios-discuss at tom.bn-ulm.de  Fri Nov 20 11:20:35 2015
From: tom-omnios-discuss at tom.bn-ulm.de (Thomas Wagner)
Date: Fri, 20 Nov 2015 12:20:35 +0100
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
	<3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
	<alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>
Message-ID: <20151120112035.GG27603@wagner-net.com>

Hi all,

On Thu, Nov 19, 2015 at 05:02:03PM -0600, Bob Friesenhahn wrote:
>  On Thu, 19 Nov 2015, Martin Waldenvik wrote:
> 
> > Hi Bob
> >
> > Why not use joyents pkgsrc. Install only apache.
[...]
>  Another possibility is to create one's own IPS repository with packages 
>  built from source code (e.g. SFE pkgbuild 
>  https://sourceforge.net/projects/pkgbuild/) and published as described at 
>  the bottom of http://omnios.omniti.com/wiki.php/Packaging.  This requires 
>  more work, but could benefit the community.
> 
>  The various SFE package collections I see targeting OmniOS are small.

Yes, that small number of packages or OmniOS can be extended to e.g.
build up a webstack which works across the various supported OS 
distributions. That way, I personally hope to share the efforts 
across the OS (S11, OI, OI-Hipster, OmniOS). 
And sharing work across the OS is one of the main goals in SFE.

A automated near continues build system is available so you can
just use the packages once they are in the SFE build scripts repo.

If we can agree on the set of packages needed and collect some examples
of basic compile settings, that would help my attempt to esablish such
a webstack.

What should be contained in such a webstack? I believe we might need
variants like using apache or nginx or <some_other_popular_webserver>,
then PHP as apache module and as fastcgi.
Besides that, usually a database like mysql_derivate and postgresql
should be available. Some OS might use the database delivered by the
OS; but I personally prefer to say independent of the underlaying OS,
if possible.

Regards
Thomas

From johan.kragsterman at capvert.se  Fri Nov 20 11:46:09 2015
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Fri, 20 Nov 2015 12:46:09 +0100
Subject: [OmniOS-discuss] can't log in as root
Message-ID: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>


Hi!

Got a small problem here:

I can log in as normal on ssh, and su to root without any problems. 

But I can't login as root directly at console/screen, but I can log in as normal user @screen, but not su to root...

What could have happened...?

Rgrds Johan



From johan.kragsterman at capvert.se  Fri Nov 20 12:38:57 2015
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Fri, 20 Nov 2015 13:38:57 +0100
Subject: [OmniOS-discuss] Ang:  can't log in as root
In-Reply-To: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
References: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
Message-ID: <OFF80EECDC.D327C528-ONC1257F03.00457C27-C1257F03.00457C29@inse.com>


Hi!


Solved it...

Stupid thing, of coarse...

I use a kvm switch to reach the console screen, and I had changed the keyboard from a usb keyboard to a ps2. So the problem must be in the kvm switch. As soon as I changed back to the original usb keyboard it worked again. Strange, since I saw no differencies in the caracters on the ps2 keyboard.

Johan


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: "omnios-discuss" <omnios-discuss at lists.omniti.com>
Fr?n: Johan Kragsterman 
S?nt av: "OmniOS-discuss" 
Datum: 2015-11-20 13:13
?rende: [OmniOS-discuss] can't log in as root

Hi!

Got a small problem here:

I can log in as normal on ssh, and su to root without any problems. 

But I can't login as root directly at console/screen, but I can log in as normal user @screen, but not su to root...

What could have happened...?

Rgrds 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 Nov 20 13:07:48 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 20 Nov 2015 08:07:48 -0500
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
Message-ID: <4C24EA92-17B7-449A-AD96-1F99793E7037@omniti.com>


> On Nov 19, 2015, at 3:58 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> What is the best way to obtain and install Apache for OmniOS r151016 which works properly and will survive the regular upgrade process?  I am really surprised to not find Apache in the standard OmniOS packages.

Keep Your Stuff To Yourself --> it was THE design decision behind OmniOS.  apache is part of that.  Hell, recent discussions have convinced me that openjdk needs to go away completely as well (we only have it because of illumos's poold).

> I spotted "group/feature/amp" but it does not work since the packages it depends on do not exist.  I do not want this whole group anyway since I have no use for MySQL and PHP.

OmniTI publishes, but doesn't support publicly, the "omniti-ms" repo, which contains a LOT of extras.  Basically, it's the repo that OmniTI uses in-house for its deployments.  I JUST put back a change that allows its packages to be more forgiving in the face of OmniOS upgrades (e.g. a package built for r151014 should work on r151014 AND LATER, not just r151014).

	pkg add-publisher -g http://pkg.omniti.com/omniti-ms/ ms.omniti.com

As I said, though, it's not officially supported for anyone beyond OmniTI internal users, but it's available for anyone who wants to Just Use It.  And it has a source repo, similar to the omnios-build one:

	https://github.com/omniti-labs/omniti-ms/

it's a bit more simplistic than omnios-build, however (no buildctl, and you just invoke individual build.sh as you see fit).

Dan


From omnios at citrus-it.net  Fri Nov 20 13:15:56 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Fri, 20 Nov 2015 13:15:56 +0000 (UTC)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <E2337C6B-853B-43AB-9560-0AB1A917A6B5@omniti.com>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<06949398-8649-44DA-97E4-3B0F81873626@omniti.com>
	<1e1501d11808$e2456a20$a6d03e60$@acm.org>
	<E2337C6B-853B-43AB-9560-0AB1A917A6B5@omniti.com>
Message-ID: <alpine.GSO.2.00.1511201313110.12108@erncre.pvgehf-vg.arg>


On Thu, 5 Nov 2015, Dan McDonald wrote:
;
; Next update of 016 (and first release of 017 bloody) will have sendmail set to dependency=group.  It'll install, but if you "pkg uninstall sendmail" just once it'll stay uninstalled throughout future updates.  (Will need to be uninstalled on your non-global zones as well.)

Thanks for this Dan, we've now finished upgrading all of our servers to
016 with no issues encountered. The 'avoid' we already have in place for the
sendmail package worked fine with this change.

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From omnios at citrus-it.net  Fri Nov 20 13:22:18 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Fri, 20 Nov 2015 13:22:18 +0000 (UTC)
Subject: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
In-Reply-To: <1e1301d11808$ab08f130$011ad390$@acm.org>
References: <alpine.GSO.2.00.1503071035370.25950@areb.pvgehf-vg.arg>
	<20150309040719.GS25463@bender.unx.csupomona.edu>
	<24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com>
	<alpine.GSO.2.00.1503091454530.1527@areb.pvgehf-vg.arg>
	<C714006B-9D09-4D3D-A4C9-A02171FEDDB4@omniti.com>
	<alpine.GSO.2.00.1511040024370.12685@erncre.pvgehf-vg.arg>
	<53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com>
	<20151104023917.GA3405@bender.unx.cpp.edu>
	<20151104080045.GA24984@gutsman.lotheac.fi>
	<ECBC3ADC-FC36-43BC-83FF-0DDD99069D16@omniti.com>
	<alpine.GSO.2.00.1511042230220.11512@erncre.pvgehf-vg.arg>
	<1e1301d11808$ab08f130$011ad390$@acm.org>
Message-ID: <alpine.GSO.2.00.1511201316310.13591@erncre.pvgehf-vg.arg>


On Thu, 5 Nov 2015, Paul B. Henson wrote:

; > From: Andy Fiddaman
; > Sent: Wednesday, November 04, 2015 2:45 PM
; >
; > Not directly. I install my own Sendmail package (which lives in
; > /opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
; > etc., replacing mailwrapper.
;
; Out of curiosity, as long as you are installing a replacement MTA, why stick
; with Sendmail instead of one of the other more modern alternatives?

I've lots of experience with Sendmail (both the open source MTA and the
commercial offerings) and our main application is built around it. The
flexibility that the rulesets provide (over and above what can be done
with milters) is important to us.
We did experiment with Postfix a few years back when it gained a milter
interface of its own but stuck with Sendmail.

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From natxo.asenjo at gmail.com  Fri Nov 20 13:24:19 2015
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 20 Nov 2015 14:24:19 +0100
Subject: [OmniOS-discuss] import zpool in freebsd/linux
Message-ID: <CAHBEJzXebRkGJxiecAPim0_jGPs05byhLRDge+RvU2Z-bUXX=g@mail.gmail.com>

hi,

for reasons not relevant for a discussion here I need to move the data on
on a on omnios zpool to a linux (preferably) ZoL installation or to freebsd
(second choice).


This is a data zpool, not rpool. So would it work to install another OS on
the disks allocated to the rpool and then importing the data zpool?

Or do I need to make a data migration copying stuff around with extra
hardware?

Thanks for any inputs on this matter.

--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151120/461fef4e/attachment-0001.html>

From omnios at citrus-it.net  Fri Nov 20 13:31:59 2015
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Fri, 20 Nov 2015 13:31:59 +0000 (UTC)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
Message-ID: <alpine.GSO.2.00.1511201328430.16586@erncre.pvgehf-vg.arg>


On Tue, 3 Nov 2015, Dan McDonald wrote:

; Say hello to OmniOS r151016:
;
; 	- New installs get OpenSSH by default, and OpenSSH is now easier to switch to or from.  (Thanks to Lauri "lotheac" Tirkkonen for this!)

Thanks for this, we've finished switching over to OpenSSH across our servers
now (and can finally drop the local SunSSH patches that we've been running!)

Two things that might be worth adding to the Release Notes wiki page in
addition to the SSH migration notes already there:

To continue allowing connections from SunSSH (during migration for example),
add:

	KexAlgorithms +diffie-hellman-group1-sha1

to sshd_config.

Remember to update any entries in /etc/pam.conf

We needed:

	s/sshd-kbdint/sshd/

to re-enable our two-factor authentication.

Andy

-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From jdg117 at elvis.arl.psu.edu  Fri Nov 20 13:32:49 2015
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Fri, 20 Nov 2015 08:32:49 -0500
Subject: [OmniOS-discuss] import zpool in freebsd/linux
In-Reply-To: Your message of "Fri, 20 Nov 2015 14:24:19 +0100."
	<CAHBEJzXebRkGJxiecAPim0_jGPs05byhLRDge+RvU2Z-bUXX=g@mail.gmail.com> 
References: <CAHBEJzXebRkGJxiecAPim0_jGPs05byhLRDge+RvU2Z-bUXX=g@mail.gmail.com>
Message-ID: <201511201332.tAKDWnO2011590@elvis.arl.psu.edu>

In message <CAHBEJzXebRkGJxiecAPim0_jGPs05byhLRDge+RvU2Z-bUXX=g at mail.gmail.com>
, Natxo Asenjo writes:
>This is a data zpool, not rpool. So would it work to install another OS on
>the disks allocated to the rpool and then importing the data zpool?

You should be able to boot the FreeBSD installation media to shell
and import your data pools as a test to confirm zpool/zfs feature
compatibility.

If it doesn't work, you probably want to engage the OpenZFS
mailing list.

John
groenveld at acm.org

From danmcd at omniti.com  Fri Nov 20 13:37:04 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 20 Nov 2015 08:37:04 -0500
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <alpine.GSO.2.00.1511201328430.16586@erncre.pvgehf-vg.arg>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<alpine.GSO.2.00.1511201328430.16586@erncre.pvgehf-vg.arg>
Message-ID: <913F9F8E-3593-4C56-A03C-9C77DCD2BBF6@omniti.com>


> On Nov 20, 2015, at 8:31 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> Two things that might be worth adding to the Release Notes wiki page in
> addition to the SSH migration notes already there:

"IMPORTANT NOTE 2" now added, with appropriate attribution.

Thank you!!!
Dan


From bfriesen at simple.dallas.tx.us  Fri Nov 20 15:38:43 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 20 Nov 2015 09:38:43 -0600 (CST)
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <20151120105205.GA11869@wagner-net.com>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
	<3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
	<alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>
	<20151120105205.GA11869@wagner-net.com>
Message-ID: <alpine.GSO.2.01.1511200911170.1673@freddy.simplesystems.org>

On Fri, 20 Nov 2015, Thomas Wagner wrote:
>>
>>  The various SFE package collections I see targeting OmniOS are small.
>
> Yes, that small number of packages or OmniOS can be extended to e.g.
> build up a webstack which works across the various supported OS
> distributions. That way, I personally hope to share the efforts
> across the OS (S11, OI, OI-Hipster, OmniOS).
> And sharing work across the OS is one of the main goals in SFE.

The omniti-ms repository is the only IPS repository I have found with 
apache in it.  SFE on SourceForge does not appear to have any spec 
files for apache.  I assume that this is because SFE has primarily 
targeted Oracle Solaris and OpenIndiana, which already come with 
apache.

> If we can agree on the set of packages needed and collect some examples
> of basic compile settings, that would help my attempt to esablish such
> a webstack.

Compile settings and needed dependencies for apache could be a matter 
of some debate.  My own needs are rather small and I am not at all 
happy with the with the number of packages that pkgsrc wants to pull 
in for apache (many are redundant with what OmniOS already includes), 
and the disk space which will be consumed.

This particular install is into a zone and the only Web-serving 
requirement for this zone is to offer Git and Mercurial web 
interfaces, which are based on Perl and Python CGI scripts.  Installs 
to other zones on the same system may have more significant 
requirements but not really more than what is already offered by 
apache given existing OmniOS packages.

OmniOS has a "Keep Your Stuff To Yourself" policy, but my own policy 
is to try to avoid the infection of too much "stuff".

This is the pkgsrc package dependency chain I see for various web 
server offerings.  Many of these are redundant with OmniOS packages 
and many represent functionality I will never need:

# pkgin -n install apache
calculating dependencies... done.

nothing to upgrade.
10 packages to be installed (31M to download, 114M to install):

tcp_wrappers-7.6.4
cyrus-sasl-2.1.26nb4
libuuid-2.26.2
openldap-client-2.4.42nb3
db4-4.8.30
pcre-8.37
expat-2.1.0nb1
apr-util-1.5.4nb2
apr-1.5.2
apache-2.4.16


# pkgin -n install nginx
calculating dependencies... done.

nothing to upgrade.
3 packages to be installed (17M to download, 60M to install):

perl-5.22.0
pcre-8.37
nginx-1.9.4


# pkgin -n install lighttpd
calculating dependencies... done.

nothing to upgrade.
7 packages to be installed (25M to download, 89M to install):

db4-4.8.30
tcp_wrappers-7.6.4
cyrus-sasl-2.1.26nb4
pcre-8.37
openldap-client-2.4.42nb3
lua51-5.1.5nb2
lighttpd-1.4.37


# pkgin -n install gitweb
calculating dependencies... done.

nothing to upgrade.
36 packages to be installed (53M to download, 381M to install):

p5-Business-ISBN-Data-20140910.002nb1
db4-4.8.30
p5-Net-SSLeay-1.70
p5-Net-LibIDN-0.12nb7
p5-Mozilla-CA-20150826
p5-Socket6-0.25nb1
p5-Net-IP-1.26nb3
p5-IO-Socket-INET6-2.72nb1
mit-krb5-1.10.7nb7
tcp_wrappers-7.6.4
cyrus-sasl-2.1.26nb4
p5-Business-ISBN-2.09nb1
p5-URI-1.69
p5-HTML-Tagset-3.20nb7
openldap-client-2.4.42nb3
libssh2-1.6.0
libidn-1.32
p5-GSSAPI-0.28nb6
p5-Digest-HMAC-1.03nb5
p5-Net-Domain-TLD-1.73nb1
p5-Net-DNS-1.01
p5-IO-CaptureOutput-1.11.04nb1
p5-TimeDate-2.30nb2
p5-IO-Socket-SSL-2.019
p5-Net-SMTP-SSL-1.03
p5-MailTools-2.14nb1
p5-Error-0.17024nb1
p5-Email-Valid-1.196nb1
p5-Authen-SASL-2.16nb3
expat-2.1.0nb1
curl-7.44.0
p5-HTML-Parser-3.71nb3
perl-5.22.0
p5-CGI-4.21
git-base-2.5.2
gitweb-2.5.2nb1

-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From jimklimov at cos.ru  Fri Nov 20 14:33:21 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Fri, 20 Nov 2015 15:33:21 +0100
Subject: [OmniOS-discuss] can't log in as root
In-Reply-To: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
References: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
Message-ID: <571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru>

20 ?????? 2015??. 12:46:09 CET, Johan Kragsterman <johan.kragsterman at capvert.se> ?????:
>
>Hi!
>
>Got a small problem here:
>
>I can log in as normal on ssh, and su to root without any problems. 
>
>But I can't login as root directly at console/screen, but I can log in
>as normal user @screen, but not su to root...
>
>What could have happened...?
>
>Rgrds Johan
>
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Normally since opensolaris, root is a role (not a useraccount), so indeed you can not directly log in as one, except when system is in maintenance singleuser mode. This is by design, to make audit trails more useful and overall security better.

You can use 'usermod' (IIRC) to change root back to a 'nortmal' (or was it 'user'?) account.

HTH,
Jim Klimov 
--
Typos courtesy of K-9 Mail on my Samsung Android

From tom-omnios-discuss at tom.bn-ulm.de  Fri Nov 20 16:05:22 2015
From: tom-omnios-discuss at tom.bn-ulm.de (Thomas Wagner)
Date: Fri, 20 Nov 2015 17:05:22 +0100
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <alpine.GSO.2.01.1511200911170.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
	<3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
	<alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>
	<20151120105205.GA11869@wagner-net.com>
	<alpine.GSO.2.01.1511200911170.1673@freddy.simplesystems.org>
Message-ID: <20151120160521.GC11869@wagner-net.com>

On Fri, Nov 20, 2015 at 09:38:43AM -0600, Bob Friesenhahn wrote:
>  On Fri, 20 Nov 2015, Thomas Wagner wrote:
> >>
> >>  The various SFE package collections I see targeting OmniOS are small.
> >
> > Yes, that small number of packages or OmniOS can be extended to e.g.
> > build up a webstack which works across the various supported OS
> > distributions. That way, I personally hope to share the efforts
> > across the OS (S11, OI, OI-Hipster, OmniOS).
> > And sharing work across the OS is one of the main goals in SFE.
> 
>  The omniti-ms repository is the only IPS repository I have found with apache 
>  in it.  SFE on SourceForge does not appear to have any spec files for 
>  apache.  I assume that this is because SFE has primarily targeted Oracle 
>  Solaris and OpenIndiana, which already come with apache.

The spec file for apache in the SVN is dated now, there was just no
demand for updating.

If there is enough interest in a webstack, then I believe there
will be some maintainers for the spec files.
So thank you for your examples and giving an idea for a lightwight
setup.

Your thoughts about large dependency chains, I think we could
try "optional" dependencies. So you install apache and only
install those optional packages like e.g.  openldap client
or php which are needed.

Regards,
Thomas


From bfriesen at simple.dallas.tx.us  Fri Nov 20 16:49:18 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 20 Nov 2015 10:49:18 -0600 (CST)
Subject: [OmniOS-discuss] can't log in as root
In-Reply-To: <571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru>
References: <OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
	<571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru>
Message-ID: <alpine.GSO.2.01.1511201045060.1673@freddy.simplesystems.org>

On Fri, 20 Nov 2015, Jim Klimov wrote:
>
> Normally since opensolaris, root is a role (not a useraccount), so 
> indeed you can not directly log in as one, except when system is in 
> maintenance singleuser mode. This is by design, to make audit trails 
> more useful and overall security better.

This is not the case for OmniOS.  For OmniOS root is a real user (with 
an empty password by default!) but /etc/default/login has this:

# If CONSOLE is set, root can only login on that device.
# If the specified device is /dev/console, then root can also log into
# any of the currently enabled /dev/vt/# virtual terminal devices.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console

so one can only login as root from the console.  If the current 
keyboard device is not associated with /dev/console or a /dev/vt/# 
device, then it would not be possible to login as root.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From johan.kragsterman at capvert.se  Fri Nov 20 16:57:09 2015
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Fri, 20 Nov 2015 17:57:09 +0100
Subject: [OmniOS-discuss] Ang: Re:  can't log in as root
In-Reply-To: <alpine.GSO.2.01.1511201045060.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511201045060.1673@freddy.simplesystems.org>,
	<OFCB5BEF14.B64A1320-ONC1257F03.003FD1CD-C1257F03.0040A69C@inse.com>
	<571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru>
Message-ID: <OFFE15EB3C.4B33E9AF-ONC1257F03.005D1B85-C1257F03.005D1F9F@inse.com>


Hi!


-----Bob Friesenhahn <bfriesen at simple.dallas.tx.us> skrev: -----
Till: Jim Klimov <jimklimov at cos.ru>
Fr?n: Bob Friesenhahn <bfriesen at simple.dallas.tx.us>
Datum: 2015-11-20 17:49
Kopia: Johan Kragsterman <johan.kragsterman at capvert.se>, omnios-discuss <omnios-discuss at lists.omniti.com>
?rende: Re: [OmniOS-discuss] can't log in as root

On Fri, 20 Nov 2015, Jim Klimov wrote:
>
> Normally since opensolaris, root is a role (not a useraccount), so 
> indeed you can not directly log in as one, except when system is in 
> maintenance singleuser mode. This is by design, to make audit trails 
> more useful and overall security better.

This is not the case for OmniOS. ?For OmniOS root is a real user (with 
an empty password by default!) but /etc/default/login has this:

# If CONSOLE is set, root can only login on that device.
# If the specified device is /dev/console, then root can also log into
# any of the currently enabled /dev/vt/# virtual terminal devices.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console

so one can only login as root from the console. ?If the current 
keyboard device is not associated with /dev/console or a /dev/vt/# 
device, then it would not be possible to login as root.





Ahaa, could that have been the problem when I used another keyboard from the kvm switch? That I changed to a ps2 keyboard from a usb keyboard? That it was not associated with /dev/console?


Johan


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  Fri Nov 20 20:54:11 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 20 Nov 2015 14:54:11 -0600 (CST)
Subject: [OmniOS-discuss] OmniOS r151016 is now out!
In-Reply-To: <alpine.GSO.2.00.1511201328430.16586@erncre.pvgehf-vg.arg>
References: <B450714B-B9C8-4B6D-A9C3-A3B61B7A0990@omniti.com>
	<alpine.GSO.2.00.1511201328430.16586@erncre.pvgehf-vg.arg>
Message-ID: <alpine.GSO.2.01.1511201441350.1673@freddy.simplesystems.org>

I encountered an additional issue with OpenSSH.  The issues related to 
updating to OpenSSH 7.0+ are described at 
http://www.openssh.com/legacy.html.  The problem I ran into was that 
existing user keys of type 'ssh-dss' are not accepted.  The 
work-around offered on that page (a client setting) is useless since 
the problem is on the server side.

I just achieved success using this additional setting in sshd_config:

# Public keys of type ssh-dss are now considered to be insecure
PubkeyAcceptedKeyTypes +ssh-dss

Since ssh-dss keys are now considered insecure, it is necessary for 
users to provide keys of an accepted type in authorized_keys, with an 
associated private key.  Once users have been accounted for, this 
option should be disabled.  I notice that ssh-rsa is still in the list 
of accepted types.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From henson at acm.org  Sat Nov 21 02:42:20 2015
From: henson at acm.org (Paul B. Henson)
Date: Fri, 20 Nov 2015 18:42:20 -0800
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
	<627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
Message-ID: <023f01d12406$3ef607d0$bce21770$@acm.org>

> From: Dan McDonald
> Sent: Friday, November 13, 2015 4:48 AM
> 
> So... anyone care to rewrite poold?!?  :)

Out of curiosity, how exactly did a system-level daemon like this end up
written in Java in the first place 8-/? Looks like a fair chunk of the code
is JNI glue allowing Java to call C code...


From danmcd at omniti.com  Sat Nov 21 03:19:19 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 20 Nov 2015 22:19:19 -0500
Subject: [OmniOS-discuss] Upgrading Java to OpenJDK8 - any advice?
In-Reply-To: <023f01d12406$3ef607d0$bce21770$@acm.org>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
	<627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
	<023f01d12406$3ef607d0$bce21770$@acm.org>
Message-ID: <DB21E357-5D69-4FE4-BE19-6A5E42945566@omniti.com>


> On Nov 20, 2015, at 9:42 PM, Paul B. Henson <henson at acm.org> wrote:
> 
> Out of curiosity, how exactly did a system-level daemon like this end up
> written in Java in the first place 8-/? Looks like a fair chunk of the code
> is JNI glue allowing Java to call C code...

I have NO idea.  I was in the networking, then security, group back at Sun.  This was done in OS/kernel, and you're better off asking that question on developer at illumos.

I *WILL* say that Java was hot-and-new, and other components now expunged from illumos, like the DHCP manager, were also written in Java.

Dan



From doug at will.to  Sat Nov 21 04:44:58 2015
From: doug at will.to (Doug Hughes)
Date: Fri, 20 Nov 2015 23:44:58 -0500
Subject: [OmniOS-discuss] changing sector size for pool
In-Reply-To: <DB21E357-5D69-4FE4-BE19-6A5E42945566@omniti.com>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
	<627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
	<023f01d12406$3ef607d0$bce21770$@acm.org>
	<DB21E357-5D69-4FE4-BE19-6A5E42945566@omniti.com>
Message-ID: <564FF6CA.90903@will.to>

When this pool was setup, it was with a different controller that didn't 
support > 2TB / disk. When the controller was replaced, the pool is 
still set for ashift=9, but if I try to replace a disk in it with 
another disk of exactly the same model I get the annoying error:

root at x4275-3-15-22:/root# zpool replace zpool1 c0t5000CCA22BC8F4C2d0 
c0t5000CCA3DE1719Fd0
cannot replace c0t5000CCA22BC8F4C2d0 with c0t5000CCA23DE1719Fd0: devices 
have different sector alignment

I know there's a -o ashift=9 option for Linux. Is there some sort of 
equivalent action that I can take, perhaps upgrading the existing zpool 
without having to recreate it?

Thanks


From henson at acm.org  Sat Nov 21 07:21:17 2015
From: henson at acm.org (Paul B. Henson)
Date: Fri, 20 Nov 2015 23:21:17 -0800
Subject: [OmniOS-discuss] changing sector size for pool
In-Reply-To: <564FF6CA.90903@will.to>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
	<627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
	<023f01d12406$3ef607d0$bce21770$@acm.org>
	<DB21E357-5D69-4FE4-BE19-6A5E42945566@omniti.com>
	<564FF6CA.90903@will.to>
Message-ID: <14096109-7563-442E-A6C1-43FC7CD6FCDA@acm.org>

Are you sure the replacement disk has the same physical sector size? It's not like vendors don't change specs on newer versions of the same model sometimes :(. What exactly is it? Is it by any chance one of those 4K drives with a jumper that controls whether or not it lies about the physical sector size?

> On Nov 20, 2015, at 8:44 PM, Doug Hughes <doug at will.to> wrote:
> 
> When this pool was setup, it was with a different controller that didn't support > 2TB / disk. When the controller was replaced, the pool is still set for ashift=9, but if I try to replace a disk in it with another disk of exactly the same model I get the annoying error:
> 
> root at x4275-3-15-22:/root# zpool replace zpool1 c0t5000CCA22BC8F4C2d0 c0t5000CCA3DE1719Fd0
> cannot replace c0t5000CCA22BC8F4C2d0 with c0t5000CCA23DE1719Fd0: devices have different sector alignment
> 
> I know there's a -o ashift=9 option for Linux. Is there some sort of equivalent action that I can take, perhaps upgrading the existing zpool without having to recreate it?
> 
> Thanks
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From jeffpc at josefsipek.net  Sat Nov 21 12:46:00 2015
From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek)
Date: Sat, 21 Nov 2015 07:46:00 -0500
Subject: [OmniOS-discuss] A small gotcha with switching the ssh
	&	openssh packages in OmniOS
In-Reply-To: <070601d120c8$d27a3f30$776ebd90$@acm.org>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
	<070601d120c8$d27a3f30$776ebd90$@acm.org>
Message-ID: <20151121124559.GA1360@meili.valhalla.31bits.net>

On Mon, Nov 16, 2015 at 03:45:06PM -0800, Paul B. Henson wrote:
> > From: Dan McDonald
> > Sent: Monday, November 16, 2015 2:15 PM
> > 
> > Off the top of my head, I can't *IMAGINE* such a change from localfs to
> fs-
> > local causing headaches in OpenSSH or ISC DHCP, but it'll require some
> > testing.  Also, will such a change into a backport situation (014 & 016)
> cause
> > more havoc than a major upgrade?
> 
> Not sure about dhcp, but given you couldn't even install openssh on 014
> until last week, I can't imagine anyone has become too dependent on the
> existing dependencies ;).
> 
> BTW, on the topic of openssh gotchas, I noticed that it does not seem to be
> compiled with GSSAPI/Kerberos support? Sunssh is, which makes the bundled
> openssh not quite a drop in replacement :(.

Agreed.  I guess I'll stick with sunssh on the server for now.

FWIW, it turns out building openssh with GSSAPI/Kerberos support is a PITA
on Illumos since our krb5-config doesn't know about "gssapi".  The libraries
still support it, but the openssh configure script doesn't know how to check
for it.  In case Dan decides to revisit this (and he should eventually ;) ),
here's the relevant patch from OI Hipster (which appears to come from
SmartOS):

https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openssh/patches/0028-Don-t-use-krb5-config-to-check-for-GSSAPI-on-Illumos.patch

Jeff.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)

From lists at marzocchi.net  Sat Nov 21 14:45:55 2015
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Sat, 21 Nov 2015 15:45:55 +0100
Subject: [OmniOS-discuss] A small gotcha with switching the
	ssh	&	openssh packages in OmniOS
In-Reply-To: <20151121124559.GA1360@meili.valhalla.31bits.net>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
	<070601d120c8$d27a3f30$776ebd90$@acm.org>
	<20151121124559.GA1360@meili.valhalla.31bits.net>
Message-ID: <1A80F944-56BA-4FE4-9821-93837B6CFF3B@marzocchi.net>



Il 21 novembre 2015 13:46:00 CET, Josef 

>FWIW, it turns out building openssh with GSSAPI/Kerberos support is a
>PITA
>on Illumos since our krb5-config doesn't know about "gssapi".  The
>libraries
>still support it, but the openssh configure script doesn't know how to
>check
>for it. 

I had a similar problem while trying to compile calendar-server for illumos. Gssapi was there but the scripts didn't know how to check for it. 

Olaf

From mailinglists at qutic.com  Sat Nov 21 15:38:14 2015
From: mailinglists at qutic.com (qutic development)
Date: Sat, 21 Nov 2015 16:38:14 +0100
Subject: [OmniOS-discuss] Apache for OmniOS r151016?
In-Reply-To: <alpine.GSO.2.01.1511200911170.1673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1511191451530.1673@freddy.simplesystems.org>
	<3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com>
	<alpine.GSO.2.01.1511191619280.1673@freddy.simplesystems.org>
	<20151120105205.GA11869@wagner-net.com>
	<alpine.GSO.2.01.1511200911170.1673@freddy.simplesystems.org>
Message-ID: <2FF448FF-57C4-4986-A90A-8C75A46BF7F4@qutic.com>


> The omniti-ms repository is the only IPS repository I have found with apache in it.  SFE on SourceForge does not appear to have any spec files for apache.  I assume that this is because SFE has primarily targeted Oracle Solaris and OpenIndiana, which already come with apache.

You may wanna use our ips-server [1]. Build with and for r151006 LTS and tested successfully with r151014 as well. Build scripts could be found on github [2].

- Stefan

[1] https://ips.qutic.com
[2] https://github.com/jfqd/omnios-build

From bfriesen at simple.dallas.tx.us  Sat Nov 21 15:54:26 2015
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Sat, 21 Nov 2015 09:54:26 -0600 (CST)
Subject: [OmniOS-discuss] A small gotcha with switching the ssh &
 openssh packages in OmniOS
In-Reply-To: <1A80F944-56BA-4FE4-9821-93837B6CFF3B@marzocchi.net>
References: <20151116201730.91DA47A0625@apps0.cs.toronto.edu>
	<77CA817A-9A04-4846-8E5E-6F13F89435FA@omniti.com>
	<070601d120c8$d27a3f30$776ebd90$@acm.org>
	<20151121124559.GA1360@meili.valhalla.31bits.net>
	<1A80F944-56BA-4FE4-9821-93837B6CFF3B@marzocchi.net>
Message-ID: <alpine.GSO.2.01.1511210934200.1673@freddy.simplesystems.org>

A change I am seeing here (not related to GSSAPI/Kerberos) is that 
with OpenSSH, no user login accounting is performed for remotely 
executed commands (e.g. "ssh host ls /") so that remote command 
execution (vs shell login) not appear in 'last'.  This is true if 
UsePAM is 'yes' or 'no'.  While this lessens the amount of noise, it 
makes me feel uneasy since there is no record of who executed remote 
commands via ssh.

Shell logins do show in 'last'.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From doug at will.to  Sat Nov 21 18:32:47 2015
From: doug at will.to (Doug Hughes)
Date: Sat, 21 Nov 2015 13:32:47 -0500
Subject: [OmniOS-discuss] changing sector size for pool
In-Reply-To: <14096109-7563-442E-A6C1-43FC7CD6FCDA@acm.org>
References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com>
	<B7CEC27E-9369-4CC9-99DC-9C698F8881AF@bens.me.uk>
	<F53B3C49-9C7E-462C-BD6B-5E8F723CB718@omniti.com>
	<5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk>
	<93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com>
	<CAO8hXRAG-pbkQVgPSyNPw0MzdZU-+6pn3R6+F=JQbQR+SduJcw@mail.gmail.com>
	<CAN0RhAMp5+shexowWVtCdb3FdSEHW8myoojuGYzGHmOuw5xFrw@mail.gmail.com>
	<627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com>
	<023f01d12406$3ef607d0$bce21770$@acm.org>
	<DB21E357-5D69-4FE4-BE19-6A5E42945566@omniti.com>
	<564FF6CA.90903@will.to>
	<14096109-7563-442E-A6C1-43FC7CD6FCDA@acm.org>
Message-ID: <5650B8CF.6080904@will.to>

yep:
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK1331PAGKW5RV
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK1331PAGP029V
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK1331PAGWABES
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK1334PBJH0R8S
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK1381PBG9Y3TS
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK2301PAJNW54T
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK2331PAGU6NZT
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK2331PAH0KLYT
Vendor: ATA      ,Product: HGST HDS724040AL ,Revision: A580 ,Serial No: 
PK2381PAJEUMVT

They were all bought in the same batch at the same time.  No jumpers 
have been changed on any of them. The difference now is that it the host 
has an upgraded HBA from when the zpool was originally created so that 
it can actually see the larger disks and show it in zpool list.





On 11/21/2015 2:21 AM, Paul B. Henson wrote:
> Are you sure the replacement disk has the same physical sector size? It's not like vendors don't change specs on newer versions of the same model sometimes :(. What exactly is it? Is it by any chance one of those 4K drives with a jumper that controls whether or not it lies about the physical sector size?
>
>> On Nov 20, 2015, at 8:44 PM, Doug Hughes <doug at will.to> wrote:
>>
>> When this pool was setup, it was with a different controller that didn't support > 2TB / disk. When the controller was replaced, the pool is still set for ashift=9, but if I try to replace a disk in it with another disk of exactly the same model I get the annoying error:
>>
>> root at x4275-3-15-22:/root# zpool replace zpool1 c0t5000CCA22BC8F4C2d0 c0t5000CCA3DE1719Fd0
>> cannot replace c0t5000CCA22BC8F4C2d0 with c0t5000CCA23DE1719Fd0: devices have different sector alignment
>>
>> I know there's a -o ashift=9 option for Linux. Is there some sort of equivalent action that I can take, perhaps upgrading the existing zpool without having to recreate it?
>>
>> Thanks
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From danmcd at omniti.com  Tue Nov 24 19:32:41 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 24 Nov 2015 14:32:41 -0500
Subject: [OmniOS-discuss] Cannot access CIFS with \\servername.fqdn
In-Reply-To: <2859482C466CCA42AD9B84B9F56212301506AF27@2H199.2hukwok2.local>
References: <2859482C466CCA42AD9B84B9F56212301506AF27@2H199.2hukwok2.local>
Message-ID: <F9C921B1-8854-43C2-8D9D-40ECB0C4E893@omniti.com>


> On Oct 2, 2015, at 5:26 AM, Robert A. Brock <Robert.Brock at 2hoffshore.com> wrote:
> 
> List,
>  
> I?ve got a box that?s doing this:
>  
> https://www.illumos.org/issues/1087
>  
> Trying to hit the cifs share by fqdn gets me this:
>  
> Error:
> \\server.domain.local is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
> 
> The account is not authorized to log in from this station.
> 
> But I can connect fine with \\hostname.
>  
> For added weirdness, I have another OmniOS box that isn?t exhibiting this problem.
>  
> Anybody seen this before and managed to figure out the cause?
>  

I'm so sorry I didn't see this until now.

Are the two OmniOS boxes running different versions?  There were a few CIFS/SMB fixes thrown into r151016, and more are en route.

Dan


From mmurphy at omniti.com  Wed Nov 25 18:58:05 2015
From: mmurphy at omniti.com (Marissa Murphy)
Date: Wed, 25 Nov 2015 13:58:05 -0500
Subject: [OmniOS-discuss] OmniOS 014 EC2 AMI
Message-ID: <CABT+cBCAYnMqNkyJ5sfxxQ9CJKvngpsrsRLkhvULTJ0rnbEJNA@mail.gmail.com>

Hello!

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)

Thanks!
Marissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151125/288fd93f/attachment.html>

From danmcd at omniti.com  Wed Nov 25 20:12:02 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 25 Nov 2015 15:12:02 -0500
Subject: [OmniOS-discuss] illumos 4986
Message-ID: <CE3E248D-0224-40A8-B827-80D274320D65@omniti.com>

Some of you in the audience have been wanting a solution to:

	https://illumos.org/issues/4986

Well now I have one, which will be reviewed by the OpenZFS folks likely next week:

	http://kebe.com/~danmcd/webrevs/4986/

Adventurous types can build zfs and libzfs to see how it holds up.

FYI,
Dan


From paladinemishakal at gmail.com  Mon Nov 30 11:26:04 2015
From: paladinemishakal at gmail.com (Lawrence Giam)
Date: Mon, 30 Nov 2015 19:26:04 +0800
Subject: [OmniOS-discuss] Migrate from OpenIndiana to OmniOS
Message-ID: <CAGueQCd7e+nUW2BMji3nWctv9D3D88QKpR3YEB-OtW4Q_vkOog@mail.gmail.com>

Hi All,

I have to upgrade one of my live server which is running OpenIndiana 151a7
to OmniOS R151014. This server is doing nightly replication from another
OmniOS server.

I want to know if I do the following is the recommended way:
1. export the data pool
2. then run the OmniOS LiveCD and install OmniOS over the old OS
3. reboot into the new OS and import back the data pool.
4. re-setup the ssh key and check and monitor if the replication works.

Will there be any steps that I may miss out?

Thanks & Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20151130/0c826ecc/attachment.html>

From jimklimov at cos.ru  Mon Nov 30 11:59:29 2015
From: jimklimov at cos.ru (Jim Klimov)
Date: Mon, 30 Nov 2015 12:59:29 +0100
Subject: [OmniOS-discuss] Migrate from OpenIndiana to OmniOS
In-Reply-To: <CAGueQCd7e+nUW2BMji3nWctv9D3D88QKpR3YEB-OtW4Q_vkOog@mail.gmail.com>
References: <CAGueQCd7e+nUW2BMji3nWctv9D3D88QKpR3YEB-OtW4Q_vkOog@mail.gmail.com>
Message-ID: <F63E4773-48FF-4615-87B5-A1039C6003FF@cos.ru>

30 ?????? 2015??. 12:26:04 CET, Lawrence Giam <paladinemishakal at gmail.com> ?????:
>Hi All,
>
>I have to upgrade one of my live server which is running OpenIndiana
>151a7
>to OmniOS R151014. This server is doing nightly replication from
>another
>OmniOS server.
>
>I want to know if I do the following is the recommended way:
>1. export the data pool
>2. then run the OmniOS LiveCD and install OmniOS over the old OS
>3. reboot into the new OS and import back the data pool.
>4. re-setup the ssh key and check and monitor if the replication works.
>
>Will there be any steps that I may miss out?
>
>Thanks & Regards.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

I'd copy the current rootfs to the data pool, so i could snatch configs from /etc and stuff in the new OS (can include not only ssh, but dladm, ipadm, rbac settings etc.). Perhaps also 'svccfg export' those smf services i have interest in.

Note that the common install procedure would wipe and recreate your zpool completely. You might want instead to 'zfs recv' an installation of new OS into a dataset on existing rpool.
--
Typos courtesy of K-9 Mail on my Samsung Android

