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: 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: 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: <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: 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 ????: Tuesday, October 27, 2015 13:40 ????: Re: [OmniOS-discuss] OmniOS backup box hanging regularly ???? (To): Jim Klimov ????? (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: 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: References: 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: <20151102112202.GA25290@gutsman.lotheac.fi> Message-ID: 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 ????: 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: 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: References: <20151102112202.GA25290@gutsman.lotheac.fi> 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: 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: 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: On Wed, Oct 14, 2015 at 7:45 PM, Dan McDonald 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: mail_msg Type: application/octet-stream Size: 601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nightly.log Type: application/octet-stream Size: 3032 bytes Desc: not available URL: 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: References: <562E912A.80808@btconnect.com> <43AF2ECC-D806-47BD-B313-23DAFE7F4563@omniti.com> <562FAE66.8080704@btconnect.com> Message-ID: 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: 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: References: Message-ID: 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 : > 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: 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: References: 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: 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: References: Message-ID: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> > On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer 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: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> Message-ID: > On Nov 3, 2015, at 4:49 PM, Dan McDonald 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: References: <5F96D535-2A98-4467-B573-CD1F9E329152@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 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 /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 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: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> <56393283.3020706@gmx.li> Message-ID: <20151104000735.7075fdc7@sleipner.datanom.net> On Tue, 03 Nov 2015 23:17:39 +0100 Dominik Hassler 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> <56393283.3020706@gmx.li> <20151104000735.7075fdc7@sleipner.datanom.net> Message-ID: <56394001.2040509@gmx.li> no I can't: pkg -R /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 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: <5F96D535-2A98-4467-B573-CD1F9E329152@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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: There are 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: 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: <5F96D535-2A98-4467-B573-CD1F9E329152@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 wrote: > > no I can't: > > pkg -R /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 /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: <5F96D535-2A98-4467-B573-CD1F9E329152@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 wrote: >> >> no I can't: >> >> pkg -R /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 /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: <5F96D535-2A98-4467-B573-CD1F9E329152@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: > On Nov 3, 2015, at 7:17 PM, 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. 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: References: <5F96D535-2A98-4467-B573-CD1F9E329152@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: <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 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> Message-ID: 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> Message-ID: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> > On Nov 3, 2015, at 7:31 PM, Andy Fiddaman 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: <5F96D535-2A98-4467-B573-CD1F9E329152@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 wrote: >>> >>> no I can't: >>> >>> pkg -R /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 /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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <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: 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: References: 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: References: 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: <20151104123045.GB24984@gutsman.lotheac.fi> Message-ID: <6F79DD03-7089-4148-8171-6002714D23E9@omniti.com> > On Nov 4, 2015, at 7:30 AM, Lauri Tirkkonen 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: 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 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> Message-ID: 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 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> 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: <5639F624.9050602@gmx.net> Message-ID: > On Nov 4, 2015, at 7:12 AM, Sebastian Gabler 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: <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 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: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> Message-ID: 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 : > > > On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer > 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: 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: References: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.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 > 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 >: > > > > On Nov 3, 2015, at 3:43 PM, Jacob Vosmaer > > 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 > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: S/MIME Cryptographic Signature URL: 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <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: References: 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: 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <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" 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> 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> <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: Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC9056A30@vEX01.mindstorm-internet.local> Hi All, Already found the issue. Mbuffer, provided by 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: 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: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> <563A4CCC.4030200@genashor.com> Message-ID: 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <20151104202932.GD3405@bender.unx.cpp.edu> Message-ID: 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> Message-ID: 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> Message-ID: <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> > On Nov 4, 2015, at 5:44 PM, 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? 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: References: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> <563A4CCC.4030200@genashor.com> 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." References: <5F96D535-2A98-4467-B573-CD1F9E329152@omniti.com> Message-ID: <201511050330.tA53Usk0026833@elvis.arl.psu.edu> In message , 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> 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 >>> 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 > ::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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> Message-ID: On Wed, 4 Nov 2015, Dan McDonald wrote: ; ; > On Nov 4, 2015, at 5:44 PM, 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? ; ; 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: References: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> 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 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 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <20151104202932.GD3405@bender.unx.cpp.edu> 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> 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 ... 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> <1e1501d11808$e2456a20$a6d03e60$@acm.org> Message-ID: > On Nov 5, 2015, at 3:30 PM, Paul B. Henson 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> <1e1501d11808$e2456a20$a6d03e60$@acm.org> 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <1e1301d11808$ab08f130$011ad390$@acm.org> Message-ID: 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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 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 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <1e1301d11808$ab08f130$011ad390$@acm.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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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 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: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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 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 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: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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 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 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 wrote: > > On 05/11/2015 14:57, Dan McDonald wrote: >> >>> On Nov 5, 2015, at 6:38 AM, Al Slater 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 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 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 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 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: > On Nov 6, 2015, at 10:57 AM, Al Slater 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: 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: <964395C2-376C-48A1-BFE8-A655EB667992@omniti.com> > On Nov 6, 2015, at 11:25 AM, Dan McDonald wrote: > >> On Nov 6, 2015, at 10:57 AM, Al Slater 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: 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: 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: 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: <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: <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <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> <563D178E.8090401@hfg-gmuend.de> Message-ID: 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 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: 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 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: 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> <563D178E.8090401@hfg-gmuend.de> 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 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: References: 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" 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 To: Al Slater Cc: OmniOS-discuss 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 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 To: Dan McDonald Cc: OmniOS-discuss 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 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 To: OmniOS-discuss Subject: Re: [OmniOS-discuss] ILB memory leak? Message-ID: Content-Type: text/plain; charset=windows-1252 > On Nov 6, 2015, at 10:57 AM, Al Slater 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 To: OmniOS-discuss 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 wrote: > >> On Nov 6, 2015, at 10:57 AM, Al Slater 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 To: Dan McDonald Cc: OmniOS-discuss Subject: Re: [OmniOS-discuss] ILB memory leak? Message-ID: 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 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" To: "'Dale Ghent'" , "'Lauri Tirkkonen'" 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: <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: <56391DE6.6050807@genashor.com> Message-ID: 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. 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: 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: References: <1A3D1B20-9C33-4514-9956-5303F6BD320A@omniti.com> Message-ID: 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 > > > 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: References: <20151108232537.92A237A046D@apps0.cs.toronto.edu> Message-ID: 9 ?????? 2015??. 0:40:20 CET, Bob Friesenhahn ?????: >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: References: <20151108232537.92A237A046D@apps0.cs.toronto.edu> 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> <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: 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> <964395C2-376C-48A1-BFE8-A655EB667992@omniti.com> <5640A22D.9000503@scluk.com> Message-ID: > On Nov 9, 2015, at 8:39 AM, Al Slater 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. 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: 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> <964395C2-376C-48A1-BFE8-A655EB667992@omniti.com> <5640A22D.9000503@scluk.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 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: 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: 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: <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> <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> <56419F61.2050905@scluk.com> <5641A1AE.6030808@scluk.com> Message-ID: > On Nov 10, 2015, at 2:50 AM, Al Slater 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: 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> <56419F61.2050905@scluk.com> <5641A1AE.6030808@scluk.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 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: 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: References: Message-ID: <36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com> > On Nov 10, 2015, at 2:42 PM, Richard PALO 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: <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 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: References: 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: <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 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: <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 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: <56425E9D.4040209@btconnect.com> Message-ID: <140450AB-E642-4C0C-A060-2C76F67DFB8A@omniti.com> > On Nov 10, 2015, at 4:16 PM, Richard Skelton 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: <56425E9D.4040209@btconnect.com> <140450AB-E642-4C0C-A060-2C76F67DFB8A@omniti.com> Message-ID: > On Nov 10, 2015, at 5:16 PM, Dan McDonald wrote: > > I'll need to dig down into this. I found it. This fix: commit bf8c2c3ce2a697c5bbe04f2b83f770cf9a59c981 Author: Dan McDonald 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: <36CA50E1-4A6C-4886-9AAB-F614301D23CB@omniti.com> Message-ID: <7E73510F-271B-4D7F-8C3A-1FE098D725B7@cos.ru> 10 ?????? 2015??. 21:54:27 CET, Dan McDonald ?????: > >> On Nov 10, 2015, at 2:42 PM, Richard PALO 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> Message-ID: > On Nov 11, 2015, at 4:50 PM, Ben Summers 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: On Wed, Nov 11, 2015 at 8:22 PM, Dan McDonald 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: 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> Message-ID: <73D39164-4616-4A0E-B769-741DB8C258B0@cos.ru> 12 ?????? 2015??. 0:17:38 CET, Peter Tribble ?????: >On Wed, Nov 11, 2015 at 8:22 PM, Dan McDonald >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> <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 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> Message-ID: <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> > On 11 Nov 2015, at 21:58, Dan McDonald wrote: > > >> On Nov 11, 2015, at 4:50 PM, Ben Summers 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> <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 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> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> Message-ID: On Thu, Nov 12, 2015 at 10:29 AM, Dan McDonald wrote: > >> On Nov 12, 2015, at 7:20 AM, Ben Summers 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: 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= 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: -------------- 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: 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> Message-ID: 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 wrote: > On Thu, Nov 12, 2015 at 10:29 AM, Dan McDonald wrote: >> >>> On Nov 12, 2015, at 7:20 AM, Ben Summers 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> Message-ID: <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com> > On Nov 13, 2015, at 5:47 AM, Ludovic Orban 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: 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 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/ 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: References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com> Message-ID: On Fri, Nov 13, 2015 at 2:13 PM, Dan McDonald 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: 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: References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@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: 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: 13 ?????? 2015??. 21:36:49 CET, Dan McDonald ?????: > >> On Nov 13, 2015, at 3:26 PM, Geoff Nordli 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/ 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: References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@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> <5646550F.8080706@genashor.com> Message-ID: <320AC536-C88A-4A2C-8CF1-B9649F9F4ABB@cos.ru> 13 ?????? 2015??. 22:24:31 CET, Gary Gendel ?????: >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> <56466EF6.70103@gmx.li> Message-ID: 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 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 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: 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: 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: > On Nov 15, 2015, at 5:16 PM, John D Groenveld 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: References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> Message-ID: > On Nov 15, 2015, at 5:52 PM, Brian Hechinger 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." References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> Message-ID: <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> In message , 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> <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 wrote: > > In message , 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> <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 wrote: > > In message , 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> <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 wrote: >> >> In message , 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> Message-ID: 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 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 wrote: >>> >>> In message , 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 ::.. CC: OmniOS-discuss (omnios-discuss at lists.omniti.com) ; Dan McDonald 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 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 value='file://localhost/etc/ssh/sshd_config' /> bloody(cmd/ssh)[0]% bloody(build/openssh)[0]% grep local * | grep -v build.log ssh.xml: 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: References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> 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 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 wrote: >>>> >>>> In message , 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> Message-ID: 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 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 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 wrote: >>>>> >>>>> In message , 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: References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> 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 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 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 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 wrote: >>>>>> >>>>>> In message , 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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: 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 wrote: > > >> On Nov 17, 2015, at 2:38 PM, Brian Hechinger 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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: 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 wrote: > > > On Nov 17, 2015, at 2:38 PM, Brian Hechinger 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: 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: References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <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: <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> > On Nov 17, 2015, at 2:57 PM, Brian Hechinger 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> Message-ID: <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> prtconf output: 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 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 wrote: > > >> On Nov 17, 2015, at 2:57 PM, Brian Hechinger 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: 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> Message-ID: > On Nov 17, 2015, at 3:23 PM, Brian Hechinger 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: References: <9F7A6807-3818-4668-8CAF-D023DAABFBC7@4amlunch.net> <201511152216.tAFMG59o016126@elvis.arl.psu.edu> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> Message-ID: <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net> > On Nov 17, 2015, at 3:53 PM, Dan McDonald wrote: > > >> On Nov 17, 2015, at 3:23 PM, Brian Hechinger 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> <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 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net> <3878828F-A0D4-41E7-BD08-175CC7593E1B@omniti.com> Message-ID: 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 wrote: > > >> On Nov 17, 2015, at 4:28 PM, Brian Hechinger 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> <201511152311.tAFNBDrJ017137@elvis.arl.psu.edu> <2A351D4A-964B-48F3-8213-901DEB5C1AB4@4amlunch.net> <56498918.3040603@gmail.com> <564ACC31.2060707@gmail.com> <201511171922.tAHJMQWX005311@elvis.arl.psu.edu> <9397937B-5579-49BF-B5AF-63D5344C3E82@4amlunch.net> <5AB47B62-F47D-4D8F-84EB-4BA6F464270A@omniti.com> <7306038E-68F4-4229-8792-DECCEBE7D35D@omniti.com> <07487C8F-05D0-4ADB-BD4F-AB0EA7AEBC40@4amlunch.net> <7263AE6E-C46D-40F4-81FB-E7FB05894A1F@4amlunch.net> Message-ID: > On Nov 17, 2015, at 4:28 PM, Brian Hechinger wrote: > >> >> On Nov 17, 2015, at 3:53 PM, Dan McDonald wrote: >> >> >>> On Nov 17, 2015, at 3:23 PM, Brian Hechinger 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: 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: References: <55FC5774-DD7A-49A4-8087-DAE2D554A0E3@omniti.com> Message-ID: <564CB929.7010308@scluk.com> On 13/11/15 20:13, Dan McDonald wrote: > 014: > ------ > > > - 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> <564CB929.7010308@scluk.com> Message-ID: <20151118185147.4b98425c@sleipner.datanom.net> Hi Dan, On Wed, 18 Nov 2015 17:45:13 +0000 Al Slater 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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> <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 wrote: > > Hi Dan, > > On Wed, 18 Nov 2015 17:45:13 +0000 > Al Slater 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > 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> <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: A 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: 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 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/ 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: 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 On Wed, Nov 18, 2015 at 10:05 PM, Geoff Nordli wrote: > On 15-11-13 12:36 PM, Dan McDonald wrote: > >> On Nov 13, 2015, at 3:26 PM, Geoff Nordli 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/ 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: 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: References: <5646475F.9010608@gnaa.net> <416533AC-E140-42AE-943A-E955CDDDE1F3@omniti.com> <564CDA09.3010505@gnaa.net> 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 > > > > > On Wed, Nov 18, 2015 at 10:05 PM, Geoff Nordli > wrote: > > On 15-11-13 12:36 PM, Dan McDonald wrote: > > On Nov 13, 2015, at 3:26 PM, Geoff Nordli > 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/ 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "It 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: 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: Hi! -----"OmniOS-discuss" skrev: ----- Till: omnios-discuss 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "It 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: References: <20151119192226.1f494d2e@sleipner.datanom.net> Message-ID: <20151119203035.67a03d68@sleipner.datanom.net> On Thu, 19 Nov 2015 19:44:23 +0100 Johan Kragsterman 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: The 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: 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: 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: 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: References: 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 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: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com> Message-ID: 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." References: Message-ID: <201511192323.tAJNNftY029365@elvis.arl.psu.edu> In message , 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. 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: References: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com> 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 , 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: 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: References: Message-ID: 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" skrev: ----- Till: "omnios-discuss" 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: References: Message-ID: <4C24EA92-17B7-449A-AD96-1F99793E7037@omniti.com> > On Nov 19, 2015, at 3:58 PM, Bob Friesenhahn 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: References: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <06949398-8649-44DA-97E4-3B0F81873626@omniti.com> <1e1501d11808$e2456a20$a6d03e60$@acm.org> Message-ID: 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: <20150309040719.GS25463@bender.unx.csupomona.edu> <24D36878-45A2-4088-86E4-AF079CF6E81B@omniti.com> <53B5201A-ACBE-4CBB-BF84-07BD466461C4@omniti.com> <20151104023917.GA3405@bender.unx.cpp.edu> <20151104080045.GA24984@gutsman.lotheac.fi> <1e1301d11808$ab08f130$011ad390$@acm.org> Message-ID: 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: 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: 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: References: Message-ID: 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." References: Message-ID: <201511201332.tAKDWnO2011590@elvis.arl.psu.edu> In message , 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: References: Message-ID: <913F9F8E-3593-4C56-A03C-9C77DCD2BBF6@omniti.com> > On Nov 20, 2015, at 8:31 AM, Andy Fiddaman 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: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com> <20151120105205.GA11869@wagner-net.com> Message-ID: 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: References: Message-ID: <571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru> 20 ?????? 2015??. 12:46:09 CET, Johan Kragsterman ?????: > >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: References: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com> <20151120105205.GA11869@wagner-net.com> 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: <571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru> Message-ID: 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: References: , <571076FF-2DD0-41E3-8C58-E1FEA7EA332F@cos.ru> Message-ID: Hi! -----Bob Friesenhahn skrev: ----- Till: Jim Klimov Fr?n: Bob Friesenhahn Datum: 2015-11-20 17:49 Kopia: Johan Kragsterman , omnios-discuss ?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: References: Message-ID: 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> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.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> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com> <023f01d12406$3ef607d0$bce21770$@acm.org> Message-ID: > On Nov 20, 2015, at 9:42 PM, Paul B. Henson 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: References: <67F9FD85-F09E-46C4-8C88-414C1D84F983@omniti.com> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com> <023f01d12406$3ef607d0$bce21770$@acm.org> 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> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com> <023f01d12406$3ef607d0$bce21770$@acm.org> <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 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: References: <3EE40478-8077-4830-8805-11BB9B751A4C@gmx.com> <20151120105205.GA11869@wagner-net.com> 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: 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> <5247FE68-CBBF-44DA-8C28-7B8D1817F40F@fluffy.co.uk> <93F86FB2-A141-4BD3-B46D-1C998C9D876B@omniti.com> <627C5746-97B8-4951-AE86-FAB38DAD7FA4@omniti.com> <023f01d12406$3ef607d0$bce21770$@acm.org> <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 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: > On Oct 2, 2015, at 5:26 AM, Robert A. Brock 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: 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: 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: 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: 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: 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: References: Message-ID: 30 ?????? 2015??. 12:26:04 CET, Lawrence Giam ?????: >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