From kaspar.schiess at absurd.li  Thu Nov  1 04:48:55 2012
From: kaspar.schiess at absurd.li (Kaspar Schiess)
Date: Thu, 1 Nov 2012 09:48:55 +0100
Subject: [OmniOS-discuss] kvm / zones
In-Reply-To: <5091B1D5.9050602@acm.org>
References: <5091B1D5.9050602@acm.org>
Message-ID: <CAPC-QMVDOTPqpPZ1B9EqVjidword10PAZHQ3XZP1NvatqR2Vow@mail.gmail.com>

Hei Paul,

> On another note, vmadm seems fairly powerful and useful for managing kvm
> instances, more so than trying to do everything by hand. It is a bit SmartOS
> centric though, I don't know if it would be useful to try to port to other
> illumos-based distributions. libvirt seems fairly popular to manage kvm
> under Linux, has anyone tried to get that working under illumos?

I've created a small launcher solution just like libvirt for OmniOS.
It will be distributed as a Ruby gem and aids in several management
tasks related to running qemu via zvols or iSCSI disks. It doesn't box
its VMs in a zone yet, but I'll look into that next - if only because
it makes resource constraining easier.

Should I notify you when that's publicly available? Or would you even
want to beta-test this? I'll release it under a MIT license once this
is documented.

regards,
kaspar

PS: Yes, it's because I do not like node one bit. But also because I
generally connect my VMs to SAN storage, something the SmartOS tools
would have to be hacked to do.

From jasonjwwilliams at gmail.com  Thu Nov  1 17:49:51 2012
From: jasonjwwilliams at gmail.com (Jason J. W. Williams)
Date: Thu, 1 Nov 2012 14:49:51 -0700
Subject: [OmniOS-discuss] OmniOS file layout & package names vs OpenIndiana
Message-ID: <CAHZAEpd4UdPWQBUCBte01t8dag1bYRPY576a+4QQGr2kWEupoQ@mail.gmail.com>

Does OmniOS diverge substantially from OpenIndiana in terms of base
filesystem layout and IPS package names? Trying to determine how much of
our Chef recipes we'd have to update to make the switch.

-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121101/eb86630b/attachment.html>

From esproul at omniti.com  Fri Nov  2 09:40:31 2012
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 2 Nov 2012 09:40:31 -0400
Subject: [OmniOS-discuss] OmniOS file layout & package names vs
	OpenIndiana
In-Reply-To: <CAHZAEpd4UdPWQBUCBte01t8dag1bYRPY576a+4QQGr2kWEupoQ@mail.gmail.com>
References: <CAHZAEpd4UdPWQBUCBte01t8dag1bYRPY576a+4QQGr2kWEupoQ@mail.gmail.com>
Message-ID: <CA+QY2RT_TikazVMuXtcYS7kaKym=JAb=pP4yK9weXs9ArWj3Aw@mail.gmail.com>

On Thu, Nov 1, 2012 at 5:49 PM, Jason J. W. Williams
<jasonjwwilliams at gmail.com> wrote:
> Does OmniOS diverge substantially from OpenIndiana in terms of base
> filesystem layout and IPS package names? Trying to determine how much of our
> Chef recipes we'd have to update to make the switch.

Hi Jason,
Since both OmniOS and OI are based on illumos, most of the packages
and therefore the filesystem layout will be the same.  Where we
diverge is the additional packages we each bring to complete the
distro.  There isn't a conscious effort to keep those package names
the same, though there is a lot of overlap.

Hope this helps,
Eric

From henson at acm.org  Fri Nov  2 16:25:49 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 02 Nov 2012 13:25:49 -0700
Subject: [OmniOS-discuss] kvm / zones
In-Reply-To: <20121101004649.GB18753@lab.pobox.com>
References: <5091B1D5.9050602@acm.org> <20121031234403.GA18753@lab.pobox.com>
	<5091B9F8.9070704@acm.org> <20121101004649.GB18753@lab.pobox.com>
Message-ID: <50942C4D.5020007@acm.org>

On 10/31/2012 5:46 PM, Bryan Horstmann-Allen wrote:

> It's actually not the joyent brand, but the kvm brand. The joyent brand is a
> modified standard "sparse" zones brand, which is (I think) very unlikely to
> work within the context of IPS (at least within the zones themselves!)

Ah, okay. I should probably just do a test install of SmartOS and get a 
little more familiarity with how it actually works, which would likely 
be helpful. Unfortunately, the only test hardware I currently have on 
hand with a sufficient Intel processor for kvm under illumos is running 
my omnios testbed :(, and since nested virtualization isn't supported 
<sigh>. I'll have to see if I can snake more hardware from someplace :).

I look forward to seeing your work on the kvm brand port when you get a 
chance, thanks...


From henson at acm.org  Fri Nov  2 16:28:16 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 02 Nov 2012 13:28:16 -0700
Subject: [OmniOS-discuss] kvm / zones
In-Reply-To: <CAPC-QMVDOTPqpPZ1B9EqVjidword10PAZHQ3XZP1NvatqR2Vow@mail.gmail.com>
References: <5091B1D5.9050602@acm.org>
	<CAPC-QMVDOTPqpPZ1B9EqVjidword10PAZHQ3XZP1NvatqR2Vow@mail.gmail.com>
Message-ID: <50942CE0.5070702@acm.org>

On 11/1/2012 1:48 AM, Kaspar Schiess wrote:

> Should I notify you when that's publicly available? Or would you even
> want to beta-test this? I'll release it under a MIT license once this
> is documented.

Why don't you post a note to the list when it's ready? I might not be 
the only one interested in taking a look...

> PS: Yes, it's because I do not like node one bit. But also because I
> generally connect my VMs to SAN storage, something the SmartOS tools
> would have to be hacked to do.

I'm sure there will be a number of changes required to vmadm to 
generalize it, supporting networked storage backends for kvm would 
probably be one of them.


From henson at acm.org  Fri Nov  2 19:16:35 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 02 Nov 2012 16:16:35 -0700
Subject: [OmniOS-discuss] CA certs redux
Message-ID: <50945453.6020909@acm.org>

After installing the latest stable release, it appears the bundled 
openssl no longer looks in the directory /usr/ssl/certs for a single 
hashed certificate by default, but instead looks for the bundled file 
/usr/ssl/cert.pem. Which didn't exist, so wget still didn't work out of 
the box.

I made a link from /etc/cacert.pem to /usr/ssl/cert.pem and it works.

Still no chance of talking you guys into a certificate directory with 
hashed links instead of a single bundled file? The former just seems so 
much more efficient...

Thanks...



From jasonjwwilliams at gmail.com  Fri Nov  2 19:37:57 2012
From: jasonjwwilliams at gmail.com (Jason J. W. Williams)
Date: Fri, 2 Nov 2012 16:37:57 -0700
Subject: [OmniOS-discuss] OmniOS file layout & package names vs
	OpenIndiana
In-Reply-To: <CA+QY2RT_TikazVMuXtcYS7kaKym=JAb=pP4yK9weXs9ArWj3Aw@mail.gmail.com>
References: <CAHZAEpd4UdPWQBUCBte01t8dag1bYRPY576a+4QQGr2kWEupoQ@mail.gmail.com>
	<CA+QY2RT_TikazVMuXtcYS7kaKym=JAb=pP4yK9weXs9ArWj3Aw@mail.gmail.com>
Message-ID: <CAHZAEpdxrZYKYm77DZVB8c6+SrVVQe+3-tG--7J94WhyNFePmQ@mail.gmail.com>

Thanks Eric, it does. We'll start combing through for differences.

-J

On Fri, Nov 2, 2012 at 6:40 AM, Eric Sproul <esproul at omniti.com> wrote:

> On Thu, Nov 1, 2012 at 5:49 PM, Jason J. W. Williams
> <jasonjwwilliams at gmail.com> wrote:
> > Does OmniOS diverge substantially from OpenIndiana in terms of base
> > filesystem layout and IPS package names? Trying to determine how much of
> our
> > Chef recipes we'd have to update to make the switch.
>
> Hi Jason,
> Since both OmniOS and OI are based on illumos, most of the packages
> and therefore the filesystem layout will be the same.  Where we
> diverge is the additional packages we each bring to complete the
> distro.  There isn't a conscious effort to keep those package names
> the same, though there is a lot of overlap.
>
> Hope this helps,
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121102/226479e9/attachment.html>

From jesus at omniti.com  Fri Nov  2 20:41:05 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 2 Nov 2012 20:41:05 -0400
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <50945453.6020909@acm.org>
References: <50945453.6020909@acm.org>
Message-ID: <CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>

I'm certainly open to it.  I think we'd still want a unified file
somewhere.  Several apps want to load all known CAs in one go, and
that is a bit easier from a file.

I thought we had fixed that particular issue.

On Fri, Nov 2, 2012 at 7:16 PM, Paul B. Henson <henson at acm.org> wrote:
> After installing the latest stable release, it appears the bundled openssl
> no longer looks in the directory /usr/ssl/certs for a single hashed
> certificate by default, but instead looks for the bundled file
> /usr/ssl/cert.pem. Which didn't exist, so wget still didn't work out of the
> box.
>
> I made a link from /etc/cacert.pem to /usr/ssl/cert.pem and it works.
>
> Still no chance of talking you guys into a certificate directory with hashed
> links instead of a single bundled file? The former just seems so much more
> efficient...
>
> Thanks...
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From jesus at omniti.com  Fri Nov  2 21:40:13 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 2 Nov 2012 21:40:13 -0400
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
Message-ID: <CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>

Paul,

I think this does the trick:
http://omnios.omniti.com/changeset.php/core/omnios-build/4c770feac5fae30efa57b8f851738d337731f4f1

It works for me in bloody right now. I'll test with it some more than
then look to roll it back into 151004.

Commit message is as follows:

Fix up cert stuff.

Place a full cert CA file in /etc/ssl/cacert.pem.
Remove it from /etc/ (it never belonged there)
Fix curl to look in /etc/ssl/cacert.pem
Unpack and hash all /etc/ssl/cacert.pem certs into /etc/ssl/certs/
Update openssl to soft link /usr/ssl/certs/ to /etc/ssl/certs/

On Fri, Nov 2, 2012 at 8:41 PM, Theo Schlossnagle <jesus at omniti.com> wrote:
> I'm certainly open to it.  I think we'd still want a unified file
> somewhere.  Several apps want to load all known CAs in one go, and
> that is a bit easier from a file.
>
> I thought we had fixed that particular issue.
>
> On Fri, Nov 2, 2012 at 7:16 PM, Paul B. Henson <henson at acm.org> wrote:
>> After installing the latest stable release, it appears the bundled openssl
>> no longer looks in the directory /usr/ssl/certs for a single hashed
>> certificate by default, but instead looks for the bundled file
>> /usr/ssl/cert.pem. Which didn't exist, so wget still didn't work out of the
>> box.
>>
>> I made a link from /etc/cacert.pem to /usr/ssl/cert.pem and it works.
>>
>> Still no chance of talking you guys into a certificate directory with hashed
>> links instead of a single bundled file? The former just seems so much more
>> efficient...
>>
>> Thanks...
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
> --
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From henson at acm.org  Fri Nov  2 22:57:42 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 02 Nov 2012 19:57:42 -0700
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
Message-ID: <50948826.3080208@acm.org>

On 11/2/2012 6:40 PM, Theo Schlossnagle wrote:

> I think we'd still want a unified file somewhere.  Several apps want
> to load all known CAs in one go, and that is a bit easier from a
> file.

Hmm, true; having both is probably best.

> I think this does the trick:

Cool, thanks. I'm not sure what changed between the previous stable and 
this one, but it looks like openssl (or at least wget) isn't looking for 
the individual hashed files anymore:

# truss wget https://www.csupomona.edu/ 2>&1 | grep /usr/ssl
open64("/usr/ssl/cert.pem", O_RDONLY)           = 3

So just putting them there might not change anything, wget will continue 
to use the single file version. If you just use 'openssl s_client' it 
doesn't even appear to have a default location, you always have to 
specify -CAfile or -CApath, so maybe it's a different version of wget 
with a different default openssl configuration? I no longer have my 
previous stable install to poke at so I'm not sure exactly. Even if I 
explicitly tell wget to use a certificate directory it still seems to 
just use the single file:

# truss wget --ca-directory=/usr/ssl/certs https://www.csupomona.edu/ 
2>&1 | grep /usr/ssl
open64("/usr/ssl/cert.pem", O_RDONLY)           = 3

Dunno 8-/. Other than wget not appearing to look for them, your diff 
looks good to me as far as creating them and making them available.

One pedantic concern is that the mozilla nss library includes its own 
bundled version of CA certs, which would potentially be different than 
these? That probably won't be a problem in practice though.

A different question, why put stuff in /usr/ssl? It looks like there are 
the certificates (which will now be linked to /etc/ssl), man pages 
(which aren't in the default man path and thus not found), a misc 
directory with the CA stuff in it, and an empty private directory.

If openssl is configured to look directly in /etc/ssl, the man pages 
were installed in /usr/share/man, that just leaves the CA directory and 
the empty private directory. It looks like at least some linux 
distributions dump the CA directory in /etc/ssl, another possibility 
would be /usr/share/openssl. I'm not sure what typically goes in the 
private directory? There's nothing in that directory on any of my stuff.

Anyway, thanks much for tuning up the certificate directory. Other than 
that, the last three paragraphs were just design idealism ;).


From jesus at omniti.com  Sat Nov  3 08:30:35 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sat, 3 Nov 2012 08:30:35 -0400
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <50948826.3080208@acm.org>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
Message-ID: <CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>

On Fri, Nov 2, 2012 at 10:57 PM, Paul B. Henson <henson at acm.org> wrote:
> On 11/2/2012 6:40 PM, Theo Schlossnagle wrote:
>
>> I think we'd still want a unified file somewhere.  Several apps want
>> to load all known CAs in one go, and that is a bit easier from a
>> file.
>
>
> Hmm, true; having both is probably best.
>
>
>> I think this does the trick:
>
>
> Cool, thanks. I'm not sure what changed between the previous stable and this
> one, but it looks like openssl (or at least wget) isn't looking for the
> individual hashed files anymore:
>
> # truss wget https://www.csupomona.edu/ 2>&1 | grep /usr/ssl
> open64("/usr/ssl/cert.pem", O_RDONLY)           = 3

Wget always acts this way. If it finds the cert.pem, it stops.  If you
remove that file, it will next stat a file in /usr/ssl/certs/.

This works on bloody.

> So just putting them there might not change anything, wget will continue to
> use the single file version. If you just use 'openssl s_client' it doesn't
> even appear to have a default location, you always have to specify -CAfile
> or -CApath, so maybe it's a different version of wget with a different
> default openssl configuration? I no longer have my previous stable install
> to poke at so I'm not sure exactly. Even if I explicitly tell wget to use a
> certificate directory it still seems to just use the single file:
>
> # truss wget --ca-directory=/usr/ssl/certs https://www.csupomona.edu/ 2>&1 |
> grep /usr/ssl
> open64("/usr/ssl/cert.pem", O_RDONLY)           = 3
>
> Dunno 8-/. Other than wget not appearing to look for them, your diff looks
> good to me as far as creating them and making them available.
>
> One pedantic concern is that the mozilla nss library includes its own
> bundled version of CA certs, which would potentially be different than
> these? That probably won't be a problem in practice though.

That concern is a real concern.  It certainly violats the principle of
least surprise.

> A different question, why put stuff in /usr/ssl? It looks like there are the
> certificates (which will now be linked to /etc/ssl), man pages (which aren't
> in the default man path and thus not found), a misc directory with the CA
> stuff in it, and an empty private directory.
>
> If openssl is configured to look directly in /etc/ssl, the man pages were
> installed in /usr/share/man, that just leaves the CA directory and the empty
> private directory. It looks like at least some linux distributions dump the
> CA directory in /etc/ssl, another possibility would be /usr/share/openssl.
> I'm not sure what typically goes in the private directory? There's nothing
> in that directory on any of my stuff.

Configuring openssl to live in /usr/ssl (which I believe is correct)
and operate on configurations in /etc/ssl is actually a pain.  That
stuff is hard coded in C

./crypto/cryptlib.h:#define X509_CERT_DIR               OPENSSLDIR "/certs"
./crypto/cryptlib.h:#define X509_CERT_FILE              OPENSSLDIR "/cert.pem"

And OPENSSLDIR influences a lot more than just those two paths.  So,
unless there is a serious issue, I think the softlink back to
/etc/ssl/... is simple and least intrusive.

> Anyway, thanks much for tuning up the certificate directory. Other than
> that, the last three paragraphs were just design idealism ;).


-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From henson at acm.org  Sun Nov  4 01:20:20 2012
From: henson at acm.org (Paul B. Henson)
Date: Sat, 3 Nov 2012 23:20:20 -0700
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
Message-ID: <20121104062020.GU4175@bender.unx.csupomona.edu>

On Sat, Nov 03, 2012 at 08:30:35AM -0400, Theo Schlossnagle wrote:

> Wget always acts this way. If it finds the cert.pem, it stops.  If you
> remove that file, it will next stat a file in /usr/ssl/certs/.

Huh, yeah, if I remove the symlink so the bundled file isn't found, it
does look for the hashed file. It seems buggy though that if I
explicitly give it the option to look for hashed files in a provided
directory it still looks for and uses the bundled file, ignoring the
option 8-/. But that's nothing to do with omnios.

> > One pedantic concern is that the mozilla nss library includes its own
> > bundled version of CA certs, which would potentially be different than
> > these? That probably won't be a problem in practice though.
> 
> That concern is a real concern.  It certainly violats the principle of
> least surprise.

Heh, I'm glad you think it's an issue :). I didn't really want to harp
on it as it seemed like I was starting to nitpick ;). I originally
suggested to Eric that rather than pull the bundled CA cert file off
curl.haxx.se that the build process for nss rip them out of the
libnssckbi.so library instead, so the nss bundled version and the
external copies were in sync. I'm not sure what the best way to approach
that is from a packaging perspective. That's actually where the current
certs in illumos-gate came from, they were pulled out of the nss version
at the time in the opensolaris repo (with the intention I suppose of
updating them when nss was updated).

> And OPENSSLDIR influences a lot more than just those two paths.  So,
> unless there is a serious issue, I think the softlink back to
> /etc/ssl/... is simple and least intrusive.

For the certs that's functional. For the man pages, with the current
layout they're not found. To make them usable, either they'd need to be
moved into the standard /usr/share/man locations or the default system
manpath would need to be extended to include /usr/ssl/man.

Thanks...


From bdha at mirrorshades.net  Sun Nov  4 11:58:43 2012
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Sun, 4 Nov 2012 11:58:43 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
Message-ID: <20121104165843.GA11278@lab.pobox.com>

Trying to build DBD::mysql against a 64bit MySQL install, and running into some
problems.

/usr/perl5/5.14.2/bin/perl:      ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
/usr/perl5/5.14.2/bin/i386/perl: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
/usr/perl5/bin/perl:     ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available

Is there a 64bit perl hiding somewhere? I was expecting to find some isaexec
wrappers! ;-)

OmniOS _does_ ship mixed modules:

/usr/perl5/5.14.2/lib/i86pc-solaris-thread-multi-64int/auto/Sun/Solaris/Kstat/Kstat.so:  ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available
/usr/perl5/5.14.2/lib/i86pc-solaris-thread-multi-64/auto/Sun/Solaris/Kstat/Kstat.so:     ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped, no debugging information available

Cheers.
-- 
bdha
cyberpunk is dead. long live cyberpunk.

From esproul at omniti.com  Sun Nov  4 12:02:34 2012
From: esproul at omniti.com (Eric Sproul)
Date: Sun, 4 Nov 2012 12:02:34 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <20121104062020.GU4175@bender.unx.csupomona.edu>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
Message-ID: <CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>

On Sun, Nov 4, 2012 at 1:20 AM, Paul B. Henson <henson at acm.org> wrote:
> Heh, I'm glad you think it's an issue :). I didn't really want to harp
> on it as it seemed like I was starting to nitpick ;). I originally
> suggested to Eric that rather than pull the bundled CA cert file off
> curl.haxx.se that the build process for nss rip them out of the
> libnssckbi.so library instead, so the nss bundled version and the
> external copies were in sync.

I agree that pulling them from libnssckbi is the most desirable
outcome, and superior to arbitrary syncing from curl.haxx.se.  I can
look into changing the mozilla-nss build process to extract these
during the build, and potentially produce the cert package as part of
the overall nss build as well.

Eric

From esproul at omniti.com  Sun Nov  4 12:39:52 2012
From: esproul at omniti.com (Eric Sproul)
Date: Sun, 4 Nov 2012 12:39:52 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
In-Reply-To: <20121104165843.GA11278@lab.pobox.com>
References: <20121104165843.GA11278@lab.pobox.com>
Message-ID: <CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>

On Sun, Nov 4, 2012 at 11:58 AM, Bryan Horstmann-Allen
<bdha at mirrorshades.net> wrote:
> Trying to build DBD::mysql against a 64bit MySQL install, and running into some
> problems.
>
> /usr/perl5/5.14.2/bin/perl:      ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
> /usr/perl5/5.14.2/bin/i386/perl: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
> /usr/perl5/bin/perl:     ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
>
> Is there a 64bit perl hiding somewhere? I was expecting to find some isaexec
> wrappers! ;-)

It's a separate package: runtime/perl-5142-64

You know, minimalism and all.  ;)

Eric

From bdha at mirrorshades.net  Sun Nov  4 13:07:08 2012
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Sun, 4 Nov 2012 13:07:08 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
In-Reply-To: <CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>
References: <20121104165843.GA11278@lab.pobox.com>
	<CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>
Message-ID: <EC6B6011-110C-45D4-9AA6-29A1ED6FA269@mirrorshades.net>

Oh, very nice. Thanks!

Was confused by 64bit kstats. :)
-- 
bdha

On Nov 4, 2012, at 12:39, Eric Sproul <esproul at omniti.com> wrote:

> On Sun, Nov 4, 2012 at 11:58 AM, Bryan Horstmann-Allen
> <bdha at mirrorshades.net> wrote:
>> Trying to build DBD::mysql against a 64bit MySQL install, and running into some
>> problems.
>> 
>> /usr/perl5/5.14.2/bin/perl:      ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
>> /usr/perl5/5.14.2/bin/i386/perl: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
>> /usr/perl5/bin/perl:     ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available
>> 
>> Is there a 64bit perl hiding somewhere? I was expecting to find some isaexec
>> wrappers! ;-)
> 
> It's a separate package: runtime/perl-5142-64
> 
> You know, minimalism and all.  ;)
> 
> Eric
> 

From esproul at omniti.com  Sun Nov  4 13:16:06 2012
From: esproul at omniti.com (Eric Sproul)
Date: Sun, 4 Nov 2012 13:16:06 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
In-Reply-To: <EC6B6011-110C-45D4-9AA6-29A1ED6FA269@mirrorshades.net>
References: <20121104165843.GA11278@lab.pobox.com>
	<CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>
	<EC6B6011-110C-45D4-9AA6-29A1ED6FA269@mirrorshades.net>
Message-ID: <CA+QY2RRqJVL24n9sLS8oh_ErfDMFfiOFaifB2JVnTVBWHZYu3A@mail.gmail.com>

On Sun, Nov 4, 2012 at 1:07 PM, Bryan Horstmann-Allen
<bdha at mirrorshades.net> wrote:
> Oh, very nice. Thanks!
>
> Was confused by 64bit kstats. :)

Yeah all the Sun::Solaris stuff comes in a single package, both 32-
and 64-bit.  Perhaps that should depend on both 32- and 64-bit
runtimes (which defeats the purpose of having split runtimes) or we
should split out the 64-bit sun-solaris modules into a matching
package that depends on perl-5142-64.

Eric

From bdha at mirrorshades.net  Sun Nov  4 13:19:34 2012
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Sun, 4 Nov 2012 13:19:34 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
In-Reply-To: <CA+QY2RRqJVL24n9sLS8oh_ErfDMFfiOFaifB2JVnTVBWHZYu3A@mail.gmail.com>
References: <20121104165843.GA11278@lab.pobox.com>
	<CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>
	<EC6B6011-110C-45D4-9AA6-29A1ED6FA269@mirrorshades.net>
	<CA+QY2RRqJVL24n9sLS8oh_ErfDMFfiOFaifB2JVnTVBWHZYu3A@mail.gmail.com>
Message-ID: <A0DDBEC5-E1B5-4E9D-8373-D861022CD56D@mirrorshades.net>

I'd prefer to just have both 32/64 Perl in base, if Perl is in base at all. For me, that's least surprise.

Creates precedence, too. If you add node to base, how will you handle it?
-- 
bdha

On Nov 4, 2012, at 13:16, Eric Sproul <esproul at omniti.com> wrote:

> On Sun, Nov 4, 2012 at 1:07 PM, Bryan Horstmann-Allen
> <bdha at mirrorshades.net> wrote:
>> Oh, very nice. Thanks!
>> 
>> Was confused by 64bit kstats. :)
> 
> Yeah all the Sun::Solaris stuff comes in a single package, both 32-
> and 64-bit.  Perhaps that should depend on both 32- and 64-bit
> runtimes (which defeats the purpose of having split runtimes) or we
> should split out the 64-bit sun-solaris modules into a matching
> package that depends on perl-5142-64.
> 
> Eric
> 

From henson at acm.org  Sun Nov  4 23:56:05 2012
From: henson at acm.org (Paul B. Henson)
Date: Sun, 4 Nov 2012 20:56:05 -0800
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
Message-ID: <20121105045605.GZ4175@bender.unx.csupomona.edu>

On Sun, Nov 04, 2012 at 12:02:34PM -0500, Eric Sproul wrote:

> I agree that pulling them from libnssckbi is the most desirable
> outcome, and superior to arbitrary syncing from curl.haxx.se.  I can
> look into changing the mozilla-nss build process to extract these
> during the build, and potentially produce the cert package as part of
> the overall nss build as well.

Cool, that sounds great; thanks much...


From jesus at omniti.com  Mon Nov  5 09:13:51 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 5 Nov 2012 09:13:51 -0500
Subject: [OmniOS-discuss] Whither 64bit system perl?
In-Reply-To: <A0DDBEC5-E1B5-4E9D-8373-D861022CD56D@mirrorshades.net>
References: <20121104165843.GA11278@lab.pobox.com>
	<CA+QY2RQF56NH9pwkm9C5=Wu6_oJhg3MOgs015MkbEJQ1UgAGLQ@mail.gmail.com>
	<EC6B6011-110C-45D4-9AA6-29A1ED6FA269@mirrorshades.net>
	<CA+QY2RRqJVL24n9sLS8oh_ErfDMFfiOFaifB2JVnTVBWHZYu3A@mail.gmail.com>
	<A0DDBEC5-E1B5-4E9D-8373-D861022CD56D@mirrorshades.net>
Message-ID: <CACLsApv__6ADUw6Kxo1m4_auB55nL7NV-pwuEqVBOiFqkuQryw@mail.gmail.com>

To be clear it is part of the release, it just isn't installed by
entire.  Nothing needs it.  Gcc is another great example of something
that we need, but isn't installed without specific user request.

I'd personally prefer for both perl and java to not be in the release
at all and let people install them.  In fact we don't use the system
perl for much of anything here.. instead we have
http://pkg.omniti.com/omniti-perl/en/index.shtml

It's a separate repository just for perl stuff that allow that
ecosystem to evolve at its own pace.

But, as long as perl does last in release, you'll be able to get it
(or depend on it) at runtime/perl-<version>-64

As a note bloody was juts bumped to 5.16.1.  I think if you want
_your_ version of perl, keeping  it separate is the right approach.

On Sun, Nov 4, 2012 at 1:19 PM, Bryan Horstmann-Allen
<bdha at mirrorshades.net> wrote:
> I'd prefer to just have both 32/64 Perl in base, if Perl is in base at all. For me, that's least surprise.
>
> Creates precedence, too. If you add node to base, how will you handle it?
> --
> bdha
>
> On Nov 4, 2012, at 13:16, Eric Sproul <esproul at omniti.com> wrote:
>
>> On Sun, Nov 4, 2012 at 1:07 PM, Bryan Horstmann-Allen
>> <bdha at mirrorshades.net> wrote:
>>> Oh, very nice. Thanks!
>>>
>>> Was confused by 64bit kstats. :)
>>
>> Yeah all the Sun::Solaris stuff comes in a single package, both 32-
>> and 64-bit.  Perhaps that should depend on both 32- and 64-bit
>> runtimes (which defeats the purpose of having split runtimes) or we
>> should split out the 64-bit sun-solaris modules into a matching
>> package that depends on perl-5142-64.
>>
>> Eric
>>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From esproul at omniti.com  Mon Nov  5 14:10:07 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 5 Nov 2012 14:10:07 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <20121105045605.GZ4175@bender.unx.csupomona.edu>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
Message-ID: <CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>

Paul,
http://omnios.omniti.com/changeset.php/core/omnios-build/5950477f82479c22ca2b7082a6f489d6b3462b71
changes the build process for web/ca-bundle which Theo had already
expanded to include the hashed cert files.  We now obtain the cert
data from the NSS source matching what we use to build
system/library/mozilla-nss.

Eric

From henson at acm.org  Mon Nov  5 15:07:02 2012
From: henson at acm.org (Paul B. Henson)
Date: Mon, 05 Nov 2012 12:07:02 -0800
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
Message-ID: <50981C66.4090700@acm.org>

On 11/5/2012 11:10 AM, Eric Sproul wrote:

> http://omnios.omniti.com/changeset.php/core/omnios-build/5950477f82479c22ca2b7082a6f489d6b3462b71
 > changes the build process for web/ca-bundle which Theo had already
> expanded to include the hashed cert files.  We now obtain the cert
> data from the NSS source matching what we use to build
> system/library/mozilla-nss.

Beautiful, thanks.

Any thoughts as far as making the openssl man pages available to the 
out-of-the-box man configuration?

From jesus at omniti.com  Mon Nov  5 15:12:24 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 5 Nov 2012 15:12:24 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <50981C66.4090700@acm.org>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
Message-ID: <CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>

Making the man pages accessible by default is the right thing to do.
Two options:

1) add /usr/ssl/man to the system man path as a part of the openssl
package installation
2) mogrify the paths to be the system man path.

I prefer (1), but if it is difficult to do with IPS, (2) is the
obvious solution.

Never let perfect be the enemy of better.

On Mon, Nov 5, 2012 at 3:07 PM, Paul B. Henson <henson at acm.org> wrote:
> On 11/5/2012 11:10 AM, Eric Sproul wrote:
>
>>
>> http://omnios.omniti.com/changeset.php/core/omnios-build/5950477f82479c22ca2b7082a6f489d6b3462b71
>
>> changes the build process for web/ca-bundle which Theo had already
>>
>> expanded to include the hashed cert files.  We now obtain the cert
>> data from the NSS source matching what we use to build
>> system/library/mozilla-nss.
>
>
> Beautiful, thanks.
>
> Any thoughts as far as making the openssl man pages available to the
> out-of-the-box man configuration?



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From henson at acm.org  Mon Nov  5 15:25:16 2012
From: henson at acm.org (Paul B. Henson)
Date: Mon, 05 Nov 2012 12:25:16 -0800
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
Message-ID: <509820AC.1050106@acm.org>

On 11/5/2012 12:12 PM, Theo Schlossnagle wrote:
> 1) add /usr/ssl/man to the system man path as a part of the openssl
> package installation
> 2) mogrify the paths to be the system man path.
>
> I prefer (1), but if it is difficult to do with IPS, (2) is the
> obvious solution.

It appears man is currently looking in /usr/gnu/share and /usr/share, 
there's no config file in either location. I'm not that familiar with 
the illumos man implementation, presumably a configuration file entry 
could be added to include /usr/ssl, but it seems that file should be 
owned by the man package, and updating it from the openssl package could 
be problematic. Another option would be to set the MANPATH in a login 
script. A mechanism fairly common in linux distributions is to have a 
/etc/profile.d directory which contains snippets dropped in by various 
packages that are then sucked in from the standard /etc/profile. This 
allows any package to easily add a little something to the login 
configuration. I don't think that's been very common in Solaris-based 
distributions though so it might not be the best approach.

# truss man man 2>&1 | grep open
open("/usr/gnu/share/man/man.cf", O_RDONLY)     Err#2 ENOENT
open("/usr/share/man/man.cf", O_RDONLY)         Err#2 ENOENT


From esproul at omniti.com  Mon Nov  5 17:29:23 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 5 Nov 2012 17:29:23 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <509820AC.1050106@acm.org>
References: <50945453.6020909@acm.org>
	<CACLsApvJ6RHvRyGRZn6_OtEQBcUEoP-QRdO1YfSo5w0UqTDE2A@mail.gmail.com>
	<CACLsApt_MPYDDAj+mYJZq6o3Xg2w7ZHi0k_Chw5xkuWXNazWzw@mail.gmail.com>
	<50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
	<509820AC.1050106@acm.org>
Message-ID: <CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>

On Mon, Nov 5, 2012 at 3:25 PM, Paul B. Henson <henson at acm.org> wrote:
> On 11/5/2012 12:12 PM, Theo Schlossnagle wrote:
>>
>> 1) add /usr/ssl/man to the system man path as a part of the openssl
>> package installation
>> 2) mogrify the paths to be the system man path.
>>
>> I prefer (1), but if it is difficult to do with IPS, (2) is the
>> obvious solution.
>
>
> It appears man is currently looking in /usr/gnu/share and /usr/share,
> there's no config file in either location. I'm not that familiar with the
> illumos man implementation, presumably a configuration file entry could be
> added to include /usr/ssl, but it seems that file should be owned by the man
> package, and updating it from the openssl package could be problematic.
> Another option would be to set the MANPATH in a login script. A mechanism
> fairly common in linux distributions is to have a /etc/profile.d directory
> which contains snippets dropped in by various packages that are then sucked
> in from the standard /etc/profile. This allows any package to easily add a
> little something to the login configuration. I don't think that's been very
> common in Solaris-based distributions though so it might not be the best
> approach.
>
> # truss man man 2>&1 | grep open
> open("/usr/gnu/share/man/man.cf", O_RDONLY)     Err#2 ENOENT
> open("/usr/share/man/man.cf", O_RDONLY)         Err#2 ENOENT
>

Historically this has always been a pain on Solaris, due to the lack
of something more modern like /etc/profile.d/.  Having an include
directory is mentioned in the OI-specific
https://www.illumos.org/issues/2617 so maybe if we cherry-pick just
the include idea from that and run with it, we can make progress.

So far I've found that /usr/share/man is a hard-coded default in
usr/src/cmd/man/src/man.c:

#define MANDIR      "/usr/share/man"

I'm not sure yet where /usr/gnu/share/man is coming from.

Eric

From henson at acm.org  Mon Nov  5 21:47:59 2012
From: henson at acm.org (Paul B. Henson)
Date: Mon, 5 Nov 2012 18:47:59 -0800
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>
References: <50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
	<509820AC.1050106@acm.org>
	<CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>
Message-ID: <20121106024759.GD4175@bender.unx.csupomona.edu>

On Mon, Nov 05, 2012 at 05:29:23PM -0500, Eric Sproul wrote:

> Historically this has always been a pain on Solaris, due to the lack
> of something more modern like /etc/profile.d/.  Having an include
> directory is mentioned in the OI-specific
> https://www.illumos.org/issues/2617 so maybe if we cherry-pick just
> the include idea from that and run with it, we can make progress.

That sounds like a good idea to me. I'll float it on the illumos dev
list and see if there's any interest in incorporating it into
illumos-gate directly. Even if not, there's no reason it couldn't be an
omnios value add :).

From denis at denisandyuki.net  Tue Nov  6 04:28:51 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Tue, 6 Nov 2012 20:28:51 +1100
Subject: [OmniOS-discuss] kvm / zones
In-Reply-To: <20121101004649.GB18753@lab.pobox.com>
References: <5091B1D5.9050602@acm.org> <20121031234403.GA18753@lab.pobox.com>
	<5091B9F8.9070704@acm.org> <20121101004649.GB18753@lab.pobox.com>
Message-ID: <CABOCf+hXTndcyKhhsrqV8TuHOGKP9D6DBwcP9JmRp89AmhuqNw@mail.gmail.com>

On Thu, Nov 1, 2012 at 11:46 AM, Bryan Horstmann-Allen <
bdha at mirrorshades.net> wrote:

>
> +------------------------------------------------------------------------------
> | On 2012-10-31 16:53:28, Paul B. Henson wrote:
> |
> > Cool :), although I must confess I'm not completely clear on what you're
> > working on. Implementing the joyent zone brand under omnios? Or something
> > else related to running kvm in zones?
>
> It's actually not the joyent brand, but the kvm brand. The joyent brand is
> a
> modified standard "sparse" zones brand, which is (I think) very unlikely to
> work within the context of IPS (at least within the zones themselves!)
>
> The kvm brand does some work with networking, but not too much. It just
> requires a bit of thought in how you handle getting passed VNICs vs not,
> and so
> forth. I just haven't had much time to look at it since an initial run at
> Surge.
>

I'm really interested in this, did you get any further with releasing it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121106/83309480/attachment.html>

From henson at acm.org  Thu Nov  8 15:31:50 2012
From: henson at acm.org (Paul B. Henson)
Date: Thu, 08 Nov 2012 12:31:50 -0800
Subject: [OmniOS-discuss] illumos issue 3310 root CA certs should be removed
	from illumos-gate
In-Reply-To: <redmine.journal-8522.20121108193210@illumos.org>
References: <redmine.journal-8522.20121108193210@illumos.org>
Message-ID: <509C16B6.8070807@acm.org>

Just as an FYI, the changeset removing root CA's from illumos-gate was 
accepted and integrated in commit 
520b7dcb0ddb3a8e36db755a9c840615df68b020...


From esproul at omniti.com  Thu Nov  8 15:36:54 2012
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 8 Nov 2012 15:36:54 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <20121106024759.GD4175@bender.unx.csupomona.edu>
References: <50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
	<509820AC.1050106@acm.org>
	<CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>
	<20121106024759.GD4175@bender.unx.csupomona.edu>
Message-ID: <CA+QY2RS2QoNgvaKsh26s4pm==uMGpNU7Y_MNtz=mM5VPux7iRQ@mail.gmail.com>

FYI,
I've just pushed a fix for the OpenSSL build that delivers the man
pages into /usr/share/man, but keeps them segregated in their own
sub-section directories (man1ssl, man3ssl, etc.), as a couple of them
overlap with system references.  This enables a user to find all the
SSL man pages even without the proposed profile.d directory addition.

For those that overlap with the system (passwd.1 and errstr.1), one
gets the SSL version with, e.g.:

man -s 1ssl passwd

http://omnios.omniti.com/changeset.php/core/omnios-build/bbe022bd094b97838b51f1632f1409d3d3638724
is the relevant changeset.

Eric

From henson at acm.org  Thu Nov  8 15:57:13 2012
From: henson at acm.org (Paul B. Henson)
Date: Thu, 08 Nov 2012 12:57:13 -0800
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <CA+QY2RS2QoNgvaKsh26s4pm==uMGpNU7Y_MNtz=mM5VPux7iRQ@mail.gmail.com>
References: <50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
	<509820AC.1050106@acm.org>
	<CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>
	<20121106024759.GD4175@bender.unx.csupomona.edu>
	<CA+QY2RS2QoNgvaKsh26s4pm==uMGpNU7Y_MNtz=mM5VPux7iRQ@mail.gmail.com>
Message-ID: <509C1CA9.7030707@acm.org>

On 11/8/2012 12:36 PM, Eric Sproul wrote:

> I've just pushed a fix for the OpenSSL build that delivers the man
> pages into /usr/share/man, but keeps them segregated in their own
> sub-section directories (man1ssl, man3ssl, etc.)

Cool; sounds great. I guess that means we don't need the /etc/profile.d 
feature for this after all; although I think I'll still try to push that 
through upstream as it seems generally useful.


From esproul at omniti.com  Thu Nov  8 16:10:44 2012
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 8 Nov 2012 16:10:44 -0500
Subject: [OmniOS-discuss] CA certs redux
In-Reply-To: <509C1CA9.7030707@acm.org>
References: <50948826.3080208@acm.org>
	<CACLsApu299K2uisPO5SsgSXYwfy8v-2LNf6a9sLuT+okO=Pf+w@mail.gmail.com>
	<20121104062020.GU4175@bender.unx.csupomona.edu>
	<CA+QY2RQFWU9Mb6ygCnmH1UQMqXLHk6D1Q9X+R7c0a4FOM+2u_A@mail.gmail.com>
	<20121105045605.GZ4175@bender.unx.csupomona.edu>
	<CA+QY2RSqOfg2gfkQvtR6CwOF=Wcz4vy6rRiUt5Z1L6Y8DyPwFQ@mail.gmail.com>
	<50981C66.4090700@acm.org>
	<CACLsApt8DKU1-5sRafo_ANLb2tnBZpNFnxJMm_VfBGgRtpjLyw@mail.gmail.com>
	<509820AC.1050106@acm.org>
	<CA+QY2RQ3pDJz3EdY9X6fGwxSUF5iA0Wok01ZGYoPCYAE5Um-BQ@mail.gmail.com>
	<20121106024759.GD4175@bender.unx.csupomona.edu>
	<CA+QY2RS2QoNgvaKsh26s4pm==uMGpNU7Y_MNtz=mM5VPux7iRQ@mail.gmail.com>
	<509C1CA9.7030707@acm.org>
Message-ID: <CA+QY2RSNi1SV1=R5rhu3zGF-wPqF_N67C8WWsPCFS-EbdQh2NQ@mail.gmail.com>

On Thu, Nov 8, 2012 at 3:57 PM, Paul B. Henson <henson at acm.org> wrote:
> Cool; sounds great. I guess that means we don't need the /etc/profile.d
> feature for this after all; although I think I'll still try to push that
> through upstream as it seems generally useful.
>

I'd still like to see this implemented.  I'm sure there will be other
cases where global profile change is warranted that can't be addressed
via packaging.

Eric

From sriramnrn at gmail.com  Fri Nov  9 07:28:23 2012
From: sriramnrn at gmail.com (Sriram Narayanan)
Date: Fri, 9 Nov 2012 17:58:23 +0530
Subject: [OmniOS-discuss] illumos issue 3310 root CA certs should be
 removed from illumos-gate
In-Reply-To: <509C16B6.8070807@acm.org>
References: <redmine.journal-8522.20121108193210@illumos.org>
	<509C16B6.8070807@acm.org>
Message-ID: <CANiY96biEeF6Th+_cb9wKYHQ=6CxnPZ2HAsbLPpmx4vjnV2PWQ@mail.gmail.com>

Paul, thanks for following up and taking this ahead.

Ram
On Nov 9, 2012 2:02 AM, "Paul B. Henson" <henson at acm.org> wrote:

> Just as an FYI, the changeset removing root CA's from illumos-gate was
> accepted and integrated in commit 520b7dcb0ddb3a8e36db755a9c8406**
> 15df68b020...
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121109/041f85e2/attachment.html>

From kaspar.schiess at absurd.li  Fri Nov  9 11:56:57 2012
From: kaspar.schiess at absurd.li (Kaspar Schiess)
Date: Fri, 9 Nov 2012 17:56:57 +0100
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
Message-ID: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>

Hi everyone,

As promised: here's the general public release of the toolchain I wrote for managing KVM virtual machines on OmniOS. Copy of the original announcement:

------------------------------------------------------------------------
qemu-toolkit is a small collection of tools to help with running virtual
machines on Illumos/OmniOS.

http://kschiess.bitbucket.org/qemu-toolkit/README.7.html


Installation:

gem install qemu-toolkit

Please refer to the above website for more detailed installation
instructions, including how to set up the base OS.


History / Comments:

This is the first ever release to a broader public. We've been using
these tools at our company[1] for a few months already. This can help
you build a great VM infrastructure/ private cloud, provided you know
what you're doing.

[1] http://www.technologyastronauts.ch

From jesus at omniti.com  Fri Nov  9 13:20:20 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Fri, 9 Nov 2012 13:20:20 -0500
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
In-Reply-To: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
References: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
Message-ID: <CACLsApu_Pim8oo6A30qBZSXLxYR9yu5SRpQvkdbPtdYZL8PtMw@mail.gmail.com>

This is really great!  Can you describe the setup at your company a bit
more? I'm interested in how many machines, how big, and how many VMs (of
what type) you run on each.

On Fri, Nov 9, 2012 at 11:56 AM, Kaspar Schiess <kaspar.schiess at absurd.li>wrote:

> Hi everyone,
>
> As promised: here's the general public release of the toolchain I wrote
> for managing KVM virtual machines on OmniOS. Copy of the original
> announcement:
>
> ------------------------------------------------------------------------
> qemu-toolkit is a small collection of tools to help with running virtual
> machines on Illumos/OmniOS.
>
> http://kschiess.bitbucket.org/qemu-toolkit/README.7.html
>
>
> Installation:
>
> gem install qemu-toolkit
>
> Please refer to the above website for more detailed installation
> instructions, including how to set up the base OS.
>
>
> History / Comments:
>
> This is the first ever release to a broader public. We've been using
> these tools at our company[1] for a few months already. This can help
> you build a great VM infrastructure/ private cloud, provided you know
> what you're doing.
>
> [1] http://www.technologyastronauts.ch
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121109/47dd70df/attachment.html>

From denis at denisandyuki.net  Fri Nov  9 17:17:10 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Sat, 10 Nov 2012 09:17:10 +1100
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
In-Reply-To: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
References: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
Message-ID: <CABOCf+h4NBfYdoTxmPoR=qHTnVPmAvi4o9A6HD-JZ2kQdEvbmA@mail.gmail.com>

Hi Kaspar

I'm getting the following warning messages after what I believe to be
successfully installing as per the instructions:

root at gazoo ~ # vmadm create myvm2
uninitialized constant QemuToolkit::Vmadm::FileUtils
root at gazoo ~ # vmadm start myvm2
uninitialized constant QemuToolkit::VM::FileUtils




On Sat, Nov 10, 2012 at 3:56 AM, Kaspar Schiess <kaspar.schiess at absurd.li>wrote:

> Hi everyone,
>
> As promised: here's the general public release of the toolchain I wrote
> for managing KVM virtual machines on OmniOS. Copy of the original
> announcement:
>
> ------------------------------------------------------------------------
> qemu-toolkit is a small collection of tools to help with running virtual
> machines on Illumos/OmniOS.
>
> http://kschiess.bitbucket.org/qemu-toolkit/README.7.html
>
>
> Installation:
>
> gem install qemu-toolkit
>
> Please refer to the above website for more detailed installation
> instructions, including how to set up the base OS.
>
>
> History / Comments:
>
> This is the first ever release to a broader public. We've been using
> these tools at our company[1] for a few months already. This can help
> you build a great VM infrastructure/ private cloud, provided you know
> what you're doing.
>
> [1] http://www.technologyastronauts.ch
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121110/89638744/attachment.html>

From henson at acm.org  Fri Nov  9 17:50:58 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 09 Nov 2012 14:50:58 -0800
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
In-Reply-To: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
References: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
Message-ID: <509D88D2.50602@acm.org>

On 11/9/2012 8:56 AM, Kaspar Schiess wrote:

> As promised: here's the general public release of the toolchain I
> wrote for managing KVM virtual machines on OmniOS. Copy of the
> original announcement:

vmadm is the same name as used by the smartos virtual machine management 
utility. While clearly a pretty descriptive choice :), is it your plan 
to duplicate the functionality and syntax of the existing smartos 
utility? If not, it might be confusing to have two such similar tools 
with the same name...

Thanks for the release, I'll definitely take a look at it.

From denis at denisandyuki.net  Sat Nov 10 04:58:39 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Sat, 10 Nov 2012 20:58:39 +1100
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
In-Reply-To: <7D858222-A1EA-475C-846F-7E7A26F52EB2@absurd.li>
References: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
	<CABOCf+h4NBfYdoTxmPoR=qHTnVPmAvi4o9A6HD-JZ2kQdEvbmA@mail.gmail.com>
	<7D858222-A1EA-475C-846F-7E7A26F52EB2@absurd.li>
Message-ID: <CABOCf+g9JXg3cccOfFJCkv0dETJADo=qJ-18=ef_3pu5VeXntQ@mail.gmail.com>

Still no dice ...
root at gazoo ~ # gem install qemu-toolkit
Fetching: qemu-toolkit-0.3.1.gem (100%)
Successfully installed qemu-toolkit-0.3.1
1 gem installed
Installing ri documentation for qemu-toolkit-0.3.1...
Installing RDoc documentation for qemu-toolkit-0.3.1...
root at gazoo ~ # vmadm create myvm3
uninitialized constant QemuToolkit::Vmadm::FileUtils
root at gazoo ~ # vmadm start myvm3
uninitialized constant QemuToolkit::VM::FileUtils



On Sat, Nov 10, 2012 at 7:11 PM, Kaspar Schiess <kaspar.schiess at absurd.li>wrote:

> Hi Denis,
>
> > I'm getting the following warning messages after what I believe to be
> successfully installing as per the instructions:
> >
> > root at gazoo ~ # vmadm create myvm2
> > uninitialized constant QemuToolkit::Vmadm::FileUtils
> > root at gazoo ~ # vmadm start myvm2
> > uninitialized constant QemuToolkit::VM::FileUtils
>
> You're right, I can reproduce that in some environments. Can you try
> installing 0.3.1? A simple
>
>   gem install qemu-toolkit
>
> should do the trick.
>
> kaspar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121110/93632a7d/attachment.html>

From kaspar.schiess at absurd.li  Sat Nov 10 03:11:18 2012
From: kaspar.schiess at absurd.li (Kaspar Schiess)
Date: Sat, 10 Nov 2012 09:11:18 +0100
Subject: [OmniOS-discuss] [ANN] qemu-toolkit 0.3.0
In-Reply-To: <CABOCf+h4NBfYdoTxmPoR=qHTnVPmAvi4o9A6HD-JZ2kQdEvbmA@mail.gmail.com>
References: <7ECA2A03-1EED-4147-80BD-09F37B858A29@absurd.li>
	<CABOCf+h4NBfYdoTxmPoR=qHTnVPmAvi4o9A6HD-JZ2kQdEvbmA@mail.gmail.com>
Message-ID: <7D858222-A1EA-475C-846F-7E7A26F52EB2@absurd.li>

Hi Denis, 

> I'm getting the following warning messages after what I believe to be successfully installing as per the instructions:
> 
> root at gazoo ~ # vmadm create myvm2
> uninitialized constant QemuToolkit::Vmadm::FileUtils
> root at gazoo ~ # vmadm start myvm2
> uninitialized constant QemuToolkit::VM::FileUtils

You're right, I can reproduce that in some environments. Can you try installing 0.3.1? A simple 

  gem install qemu-toolkit 

should do the trick. 

kaspar


From gate03 at landcroft.co.uk  Sat Nov 10 22:13:08 2012
From: gate03 at landcroft.co.uk (Michael Mounteney)
Date: Sun, 11 Nov 2012 13:13:08 +1000
Subject: [OmniOS-discuss] samba in a non-global zone ?
Message-ID: <135262628.aUZGyFbeuL@pimple>

Got all the services running and:

setppriv:  not owner

Don't tell me you have to run samba in the global zone "?

Oh, and where's smb.conf supposed to go ?  /etc/ ?  /etc/samba/ ?  I couldn't 
make it work.

Thanks in expectation ...

Michael.

From esproul at omniti.com  Mon Nov 12 15:09:58 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 12 Nov 2012 15:09:58 -0500
Subject: [OmniOS-discuss] Updated release r151004b and new unstable ISO
Message-ID: <CA+QY2RTmkdH_jYMiC5iR-e-Ti08u23S9UORDuqg4tVoqG2m2ig@mail.gmail.com>

OmniOS weekly release r151004b is the first interim update for the
r151004 release.  It contains a fix for ipmitool when used with the
local device (bmc) interface, as well as updating pci.ids to the
latest snapshot.

http://omnios.omniti.com/wiki.php/ReleaseNotes#r151004b

Additionally, a new unstable ("bloody") ISO is now available from
http://omnios.omniti.com/wiki.php/Installation#FromCDiso

See http://omnios.omniti.com/wiki.php/Intervals#r151005 for what's
changing and what we're working on.

From esproul at omniti.com  Tue Nov 13 09:52:01 2012
From: esproul at omniti.com (Eric Sproul)
Date: Tue, 13 Nov 2012 09:52:01 -0500
Subject: [OmniOS-discuss] samba in a non-global zone ?
In-Reply-To: <135262628.aUZGyFbeuL@pimple>
References: <135262628.aUZGyFbeuL@pimple>
Message-ID: <CA+QY2RQk651dfESkQUCtNfj6kAtEjK1RLy73tUrh2fAGv=Sxag@mail.gmail.com>

On Sat, Nov 10, 2012 at 10:13 PM, Michael Mounteney
<gate03 at landcroft.co.uk> wrote:
> Got all the services running and:
>
> setppriv:  not owner
>
> Don't tell me you have to run samba in the global zone "?
>
> Oh, and where's smb.conf supposed to go ?  /etc/ ?  /etc/samba/ ?  I couldn't
> make it work.

Hi Michael,
Did you install Samba or are you using the "sharesmb" ZFS property?
The CIFS service you get from setting "sharesmb" in ZFS is the
in-kernel CIFS service, which is why it can only be used in the global
zone.  NFS is the same way.  I believe there is effort to make NFS
serving available in non-global zones, but I'm not aware of a similar
effort for CIFS.

If you want CIFS sharing in a non-global zone, you'll need to install
Samba.  Since that's not something provided by OmniOS, the location of
config files would be determined by the package author.

HTH,
Eric

From esproul at omniti.com  Tue Nov 13 16:22:25 2012
From: esproul at omniti.com (Eric Sproul)
Date: Tue, 13 Nov 2012 16:22:25 -0500
Subject: [OmniOS-discuss] USB images now available
Message-ID: <CA+QY2RSUXCt-zGToOyZbNNxXCUUOYrk39NMSnVXvKOmkqLRwgg@mail.gmail.com>

FYI,
We now have USB installation images available for OmniOS:
http://omnios.omniti.com/wiki.php/Installation#FromUSB

You can write the image to your drive with dd.

Enjoy!

From bdha at mirrorshades.net  Tue Nov 13 16:30:05 2012
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Tue, 13 Nov 2012 14:30:05 -0700
Subject: [OmniOS-discuss] USB images now available
In-Reply-To: <CA+QY2RSUXCt-zGToOyZbNNxXCUUOYrk39NMSnVXvKOmkqLRwgg@mail.gmail.com>
References: <CA+QY2RSUXCt-zGToOyZbNNxXCUUOYrk39NMSnVXvKOmkqLRwgg@mail.gmail.com>
Message-ID: <E3D59CF3-9687-437E-8E6F-BBAFBA25CAB1@mirrorshades.net>

Very nice!
-- 
bdha

On Nov 13, 2012, at 14:22, Eric Sproul <esproul at omniti.com> wrote:

> FYI,
> We now have USB installation images available for OmniOS:
> http://omnios.omniti.com/wiki.php/Installation#FromUSB
> 
> You can write the image to your drive with dd.
> 
> Enjoy!
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 

From len at cloudafrica.net  Tue Nov 13 16:32:07 2012
From: len at cloudafrica.net (Len Weincier)
Date: Tue, 13 Nov 2012 23:32:07 +0200
Subject: [OmniOS-discuss] virtualization
Message-ID: <27386019-B136-4FD2-A920-08A1D9B0706A@cloudafrica.net>

Hi

I was wondering of there is anything in OmniOS to assist with managing zones/vms and their related disks like the vmadm commands from SmartOS ?

Thanks
Len

From henson at acm.org  Tue Nov 13 16:43:06 2012
From: henson at acm.org (Paul B. Henson)
Date: Tue, 13 Nov 2012 13:43:06 -0800
Subject: [OmniOS-discuss] virtualization
In-Reply-To: <27386019-B136-4FD2-A920-08A1D9B0706A@cloudafrica.net>
References: <27386019-B136-4FD2-A920-08A1D9B0706A@cloudafrica.net>
Message-ID: <20121113214306.GQ4175@bender.unx.csupomona.edu>

On Tue, Nov 13, 2012 at 11:32:07PM +0200, Len Weincier wrote:

> I was wondering of there is anything in OmniOS to assist with managing zones/vms and their related disks like the vmadm commands from SmartOS ?

There's nothing currently bundled. Kaspar recently released a ruby based
tool:

http://lists.omniti.com/pipermail/omnios-discuss/2012-November/000232.html

and there's been some talk of trying to port the smartos code to work
under omnios/OI, but no actual work on that yet.

From len at cloudafrica.net  Tue Nov 13 16:50:57 2012
From: len at cloudafrica.net (Len Weincier)
Date: Tue, 13 Nov 2012 23:50:57 +0200
Subject: [OmniOS-discuss] virtualization
In-Reply-To: <20121113214306.GQ4175@bender.unx.csupomona.edu>
References: <27386019-B136-4FD2-A920-08A1D9B0706A@cloudafrica.net>
	<20121113214306.GQ4175@bender.unx.csupomona.edu>
Message-ID: <14BC8E47-C3E4-423A-96F9-162096D9DA38@cloudafrica.net>


On 13 Nov 2012, at 11:43 PM, "Paul B. Henson" <henson at acm.org> wrote:

> On Tue, Nov 13, 2012 at 11:32:07PM +0200, Len Weincier wrote:
> 
>> I was wondering of there is anything in OmniOS to assist with managing zones/vms and their related disks like the vmadm commands from SmartOS ?
> 
> There's nothing currently bundled. Kaspar recently released a ruby based
> tool:

That looks great - thanks !

Len

From sergey57 at gmail.com  Thu Nov 15 16:36:12 2012
From: sergey57 at gmail.com (sergey ivanov)
Date: Thu, 15 Nov 2012 13:36:12 -0800
Subject: [OmniOS-discuss] is there workaround for zfs diff?
Message-ID: <CAAv=BDFBo8idaHnaPoRohLWMOqAaeuQjYYp-Hhm8PV-ncP21=g@mail.gmail.com>

Hi,
I have hit the bug in zfs diff implementation. Had fileserver rebooted
couple times today. It looks similar to illumos bug 3320 (
https://www.illumos.org/issues/3320).
Is there a different way to see if snapshots are equal? It looks like 'zfs
get used <snapshotname> is difficult to decrypt to understand what changes
are using this space.
-- 
Regards,
Sergey Ivanov | 443-844-6318 | sergey57 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121115/aa89553d/attachment.html>

From esproul at omniti.com  Thu Nov 15 17:28:43 2012
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 15 Nov 2012 17:28:43 -0500
Subject: [OmniOS-discuss] is there workaround for zfs diff?
In-Reply-To: <CAAv=BDFBo8idaHnaPoRohLWMOqAaeuQjYYp-Hhm8PV-ncP21=g@mail.gmail.com>
References: <CAAv=BDFBo8idaHnaPoRohLWMOqAaeuQjYYp-Hhm8PV-ncP21=g@mail.gmail.com>
Message-ID: <CA+QY2RSVakhXDibhUO9zdpOKzAs_C3cv42kiLqSphm_+v8-WNg@mail.gmail.com>

On Thu, Nov 15, 2012 at 4:36 PM, sergey ivanov <sergey57 at gmail.com> wrote:
> Hi,
> I have hit the bug in zfs diff implementation. Had fileserver rebooted
> couple times today. It looks similar to illumos bug 3320
> (https://www.illumos.org/issues/3320).
> Is there a different way to see if snapshots are equal? It looks like 'zfs
> get used <snapshotname> is difficult to decrypt to understand what changes
> are using this space.

Hi Sergey,
I think the only other way would be a recursive diff using the hidden
snapdir, e.g.:

diff -ur /foo/.zfs/snapshot/mysnap1/ /foo/.zfs/snapshot/mysnap2/

Effectively just using those separate views and treating them as any
other regular directories.

HTH,
Eric

From henson at acm.org  Fri Nov 16 23:36:12 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 16 Nov 2012 20:36:12 -0800
Subject: [OmniOS-discuss] hardware specs for illumos storage/virtualization
	server
Message-ID: <50A7143C.2040002@acm.org>

I think I'm finally going to get around to putting together the illumos 
home/hobby server I've been thinking about for the past few years :), 
and would appreciate a little feedback on parts/compatibility/design.

The box is intended to be both a storage server (music/video/etc media, 
documents, whatever) with content available via both NFS and CIFS, as 
well as a virtualization server using kvm to run some number of linux 
instances (the most heavyweight of which will probably be the mythtv 
instance, but there will be a number of other miscellaneous things going 
on). I'm thinking of using two SSD's with a partition mirrored for 
rpool, a 2nd separate partition as L2ARC on each, and possibly a third 
mirrored for slog (or potentially a separate SSD just for slog), and a 
storage pool consisting of 2 6 disk raidz2 vdevs.

For the case, I'm looking at the Supermicro 836BA-R920B rackmount 
chassis, which has 16 3.5" hot-swap bays on the front, and 2 2.5" 
hot-swap bays on the back, along with dual redundant 960w 80+ platinum 
certified power supplies. This particular model has all 16 front bays 
direct attached, with four SFF-8087 connectors. There are two other 
models available with either one or two SAS expanders; however, from 
what I understand hooking up SATA drives on the other side of a SAS 
expander is a bad idea. If I went with near-line SAS, I could get the 
model with the expanders, which would reduce my cost in terms of SAS 
controllers, but the pricing on near-line SAS is ridiculous compared to 
SATA, and the extra cost in SAS controller should be outweighed by 
reduced cost in drives (I'm already looking at a way higher budget than 
I'd like for a hobby project, but I have few vices, and electronics are 
one of them ;) ).

For the motherboard, I'm looking at the Supermicro X9DRD-7LN4F-JBOD, 
which is a dual LGA 2011 socket board with 16 DIMM slots, 2 x SATA3, 4 x 
SATA2, and 8 x SAS (LSI 2308 controller onboard) along with 4 intel i350 
based gig nics. My understanding is that illumos is perfectly happy with 
the LSI 2308 in IT mode. The -JBOD version of this motherboard comes 
from the factory with IT firmware. It doesn't seem readily available 
though, if I went with the regular version the LSI controller comes with 
RAID firmware, it's possible to reflash with IT but from what I've read 
it's a bit of a pain (you need to do it from the EFI shell). It also 
looks like illumos works with the intel i350 gig nics, and I assume 
there should be no issue with the onboard Intel AHCI SATA controller?

CPU, 2 x Intel Xeon E5-2620. The hex core is a bit pricier than the 
quads, but I've just got my heart set on 12 cores, and no one said a 
hobby had to be cost effective ;). These are Sandy Bridge Xeons, I know 
there were some Sandy Bridge issues in the past, but I think there were 
workarounds, and it looks like Joyent recently fixed them 
(https://github.com/joyent/illumos-joyent/commit/4d86fb7f59410be72e467483b74e2eebff6052b2), 
so I'm hoping they will work well.

I haven't really spec'd specific RAM, although I'm partial to crucial, 
it takes 1333MHz registered ECC DDR3. I think I want at least 32GB for 
the storage server side, and I'm not sure yet how much more I'll add in 
on top of that for virtualization.

8 of the 16 3.5" bays will be covered by the onboard LSI controller, I 
need to get an additional PCIe controller with 2 x SFF-8087 connectors 
to cover the rest. Seems there are a fair number of options, although 
I'm not sure if there's a clear winner among them. Any favorites?

Hard drives are the parts I'm least confident in 8-/. I'd like to go 2TB 
or 3TB, that's cost prohibitive for near-line SAS, and pretty darn pricy 
for "enterprise" SATA. I don't really want to go with desktop class 
drives though.

Is there any opinion yet on the new WD Red "NAS" drives? They're only 
$170 for a 3TB drive, which is pretty cheap. On the plus side, they're 
engineered for 7x24 operation, have a three year warranty, and are 
supposed to be low power/low heat (both would be good; while I installed 
a 4.5kw solar power system a few years ago when I remodeled our house, 
and have been net negative powerwise since, I anticipate that to change 
when this beast starts running. I also set up a dedicated wiring closet 
with a separate 8000btu wall air conditioner, but still less heat = less 
cooling = less power utilization). They come out-of-the-box with 7 
second TLER, plus the ability to tune that however you'd like. On the 
downside, while WD doesn't specify it, they evidently run at 5400rpm 
(where I suppose the low power low heat comes from), and aren't exactly 
screamers (streaming isn't too bad, but random IO leaves a bit to be 
desired).

My mythtv vm will potentially be recording 4 HD ATSC streams 
(originating from network connected HD homeruns), reading all 4 back 
from disk at the same time (for commercial flagging) and potentially 
reading a different two streams for playback on the two front ends I 
currently have connected to TVs. Arguably worst case for an ATSC 
transport stream is about 18Mbps, so it's not really that much. But then 
all of the vm's will be doing their thing, plus whatever NFS/CIFS 
clients are up to. Sizing for IO is black magic to me <sigh>, on the one 
hand I want to maximize my storage for the cost, but on the other I 
don't want to have recordings that skip and stutter and vm's that lag 
and are unresponsive...

I also don't really have a good handle on what SSD's to go with. As I 
mentioned, I'm thinking of getting two for rpool/l2arc, and hook them up 
to the onboard SATA3 controller. If I can find ones that are 
appropriate, I'd carve out a third partition on them for a mirrored 
slog; otherwise I'd get a separate third one and stick it in a 3.5" bay 
to be dedicated slog. I don't think I'd bother to mirror the slog if it 
is on a separate SSD, I believe there are no longer any critical failure 
modes from slog failure, worst-case being it fails when the pool is 
off-line and you need to manually import it. Any suggestions on good 
rpool/l2arc/slog SSD's, or rpool/l2arc SSD's with a different model slog 
SSD would be greatly appreciated.

Thanks much for reading so far :), I realize I've gone on for quite a 
bit... Any comments/feedback/suggestions on compatibility or design 
issues with what I've laid out would be very welcome. Thanks again...


From denis at denisandyuki.net  Sat Nov 17 07:56:48 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Sat, 17 Nov 2012 23:56:48 +1100
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <50A7143C.2040002@acm.org>
References: <50A7143C.2040002@acm.org>
Message-ID: <CABOCf+joFjjqrC2LbP8mx014VCF5qHUhfT8u6aXyPvO_7xY_og@mail.gmail.com>

That's a lot of issues and questions to raise in the one post!

Let me start off by saying that your intentions are very similar to mine.
My OmniOS box is the storage backend for my household, and this includes
MythTV as well as stackloads of photos, videos, music, etc.

My primary system's configuration is:
Intel S2600CO Motherboard (16 x DIMM slots, dual LGA2011)
Xeon E5-2603 (single CPU even though the mobo is dual capable)
8 x 16GB Hynix DDR ECC DIMMs (total 128GB)
2 x LSI 9201-16i 6G SAS cards
Norco RPC-4224 case, 24 x hotswap 6G SAS bays
OCZ ZX Series 850W power supply (note importantly this PSU has a 30A 5V
rail)
13 x 3TB WD Red drives
plus miscellaneous other less interesting stuff.

Some of these parts you might like to consider instead of the configuration
you were looking at, like the mobo, the case and the SAS cards which can
all be obtained at good prices.

With respect to the NAS drives - it's too early for me to give much
feedback on them, but they are definitely the ones to get, for the reasons
you gave.

Regarding running a MythTV backend under OmniOS:

1. It's not going to work natively, nobody that I have been able to find
has actually got a backend build working on Solaris and kept it up to date
2. It would have been a good option, but BrandZ has gone by the wayside
long ago
3. KVM as I have so far tested has some major limitations that would make
it impractical, i.e. both network bandwith and disk throughput is terrible
to the point that it will cause problems with MythTV.

The last point is the main problem for MythTV under OmniOS for me; severely
limited network throughput will cause major problems, since all recordings
will need to be through network TV tuners (HD Homeruns for me) along with
recording playback.  While the network throughput issues I saw may have
been because of the problems that I had with the aggregated network cards,
I have still not had the opportunity to properly test KVM performance since
the proposed fix was released into the bloody build.  I hope to get the
opportunity to try it in the next few weeks though.

Please keep us up to date with how you go if you do deploy a MythTV backend
into a KVM instance though, I'm interested to see your observations on
network throughput, since mine was so crippled..


On Sat, Nov 17, 2012 at 3:36 PM, Paul B. Henson <henson at acm.org> wrote:

> I think I'm finally going to get around to putting together the illumos
> home/hobby server I've been thinking about for the past few years :), and
> would appreciate a little feedback on parts/compatibility/design.
>
> The box is intended to be both a storage server (music/video/etc media,
> documents, whatever) with content available via both NFS and CIFS, as well
> as a virtualization server using kvm to run some number of linux instances
> (the most heavyweight of which will probably be the mythtv instance, but
> there will be a number of other miscellaneous things going on). I'm
> thinking of using two SSD's with a partition mirrored for rpool, a 2nd
> separate partition as L2ARC on each, and possibly a third mirrored for slog
> (or potentially a separate SSD just for slog), and a storage pool
> consisting of 2 6 disk raidz2 vdevs.
>
> For the case, I'm looking at the Supermicro 836BA-R920B rackmount chassis,
> which has 16 3.5" hot-swap bays on the front, and 2 2.5" hot-swap bays on
> the back, along with dual redundant 960w 80+ platinum certified power
> supplies. This particular model has all 16 front bays direct attached, with
> four SFF-8087 connectors. There are two other models available with either
> one or two SAS expanders; however, from what I understand hooking up SATA
> drives on the other side of a SAS expander is a bad idea. If I went with
> near-line SAS, I could get the model with the expanders, which would reduce
> my cost in terms of SAS controllers, but the pricing on near-line SAS is
> ridiculous compared to SATA, and the extra cost in SAS controller should be
> outweighed by reduced cost in drives (I'm already looking at a way higher
> budget than I'd like for a hobby project, but I have few vices, and
> electronics are one of them ;) ).
>
> For the motherboard, I'm looking at the Supermicro X9DRD-7LN4F-JBOD, which
> is a dual LGA 2011 socket board with 16 DIMM slots, 2 x SATA3, 4 x SATA2,
> and 8 x SAS (LSI 2308 controller onboard) along with 4 intel i350 based gig
> nics. My understanding is that illumos is perfectly happy with the LSI 2308
> in IT mode. The -JBOD version of this motherboard comes from the factory
> with IT firmware. It doesn't seem readily available though, if I went with
> the regular version the LSI controller comes with RAID firmware, it's
> possible to reflash with IT but from what I've read it's a bit of a pain
> (you need to do it from the EFI shell). It also looks like illumos works
> with the intel i350 gig nics, and I assume there should be no issue with
> the onboard Intel AHCI SATA controller?
>
> CPU, 2 x Intel Xeon E5-2620. The hex core is a bit pricier than the quads,
> but I've just got my heart set on 12 cores, and no one said a hobby had to
> be cost effective ;). These are Sandy Bridge Xeons, I know there were some
> Sandy Bridge issues in the past, but I think there were workarounds, and it
> looks like Joyent recently fixed them (https://github.com/joyent/**
> illumos-joyent/commit/**4d86fb7f59410be72e467483b74e2e**ebff6052b2<https://github.com/joyent/illumos-joyent/commit/4d86fb7f59410be72e467483b74e2eebff6052b2>),
> so I'm hoping they will work well.
>
> I haven't really spec'd specific RAM, although I'm partial to crucial, it
> takes 1333MHz registered ECC DDR3. I think I want at least 32GB for the
> storage server side, and I'm not sure yet how much more I'll add in on top
> of that for virtualization.
>
> 8 of the 16 3.5" bays will be covered by the onboard LSI controller, I
> need to get an additional PCIe controller with 2 x SFF-8087 connectors to
> cover the rest. Seems there are a fair number of options, although I'm not
> sure if there's a clear winner among them. Any favorites?
>
> Hard drives are the parts I'm least confident in 8-/. I'd like to go 2TB
> or 3TB, that's cost prohibitive for near-line SAS, and pretty darn pricy
> for "enterprise" SATA. I don't really want to go with desktop class drives
> though.
>
> Is there any opinion yet on the new WD Red "NAS" drives? They're only $170
> for a 3TB drive, which is pretty cheap. On the plus side, they're
> engineered for 7x24 operation, have a three year warranty, and are supposed
> to be low power/low heat (both would be good; while I installed a 4.5kw
> solar power system a few years ago when I remodeled our house, and have
> been net negative powerwise since, I anticipate that to change when this
> beast starts running. I also set up a dedicated wiring closet with a
> separate 8000btu wall air conditioner, but still less heat = less cooling =
> less power utilization). They come out-of-the-box with 7 second TLER, plus
> the ability to tune that however you'd like. On the downside, while WD
> doesn't specify it, they evidently run at 5400rpm (where I suppose the low
> power low heat comes from), and aren't exactly screamers (streaming isn't
> too bad, but random IO leaves a bit to be desired).
>
> My mythtv vm will potentially be recording 4 HD ATSC streams (originating
> from network connected HD homeruns), reading all 4 back from disk at the
> same time (for commercial flagging) and potentially reading a different two
> streams for playback on the two front ends I currently have connected to
> TVs. Arguably worst case for an ATSC transport stream is about 18Mbps, so
> it's not really that much. But then all of the vm's will be doing their
> thing, plus whatever NFS/CIFS clients are up to. Sizing for IO is black
> magic to me <sigh>, on the one hand I want to maximize my storage for the
> cost, but on the other I don't want to have recordings that skip and
> stutter and vm's that lag and are unresponsive...
>
> I also don't really have a good handle on what SSD's to go with. As I
> mentioned, I'm thinking of getting two for rpool/l2arc, and hook them up to
> the onboard SATA3 controller. If I can find ones that are appropriate, I'd
> carve out a third partition on them for a mirrored slog; otherwise I'd get
> a separate third one and stick it in a 3.5" bay to be dedicated slog. I
> don't think I'd bother to mirror the slog if it is on a separate SSD, I
> believe there are no longer any critical failure modes from slog failure,
> worst-case being it fails when the pool is off-line and you need to
> manually import it. Any suggestions on good rpool/l2arc/slog SSD's, or
> rpool/l2arc SSD's with a different model slog SSD would be greatly
> appreciated.
>
> Thanks much for reading so far :), I realize I've gone on for quite a
> bit... Any comments/feedback/suggestions on compatibility or design issues
> with what I've laid out would be very welcome. Thanks again...
>
> ______________________________**_________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.**com <OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/**mailman/listinfo/omnios-**discuss<http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121117/6c921299/attachment-0001.html>

From henson at acm.org  Sun Nov 18 01:33:32 2012
From: henson at acm.org (Paul B. Henson)
Date: Sat, 17 Nov 2012 22:33:32 -0800
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <CABOCf+joFjjqrC2LbP8mx014VCF5qHUhfT8u6aXyPvO_7xY_og@mail.gmail.com>
References: <50A7143C.2040002@acm.org>
	<CABOCf+joFjjqrC2LbP8mx014VCF5qHUhfT8u6aXyPvO_7xY_og@mail.gmail.com>
Message-ID: <20121118063332.GZ4175@bender.unx.csupomona.edu>

On Sat, Nov 17, 2012 at 11:56:48PM +1100, Denis Cheong wrote:
> That's a lot of issues and questions to raise in the one post!

Sorry :), it was either that or post a dozen different threads ;).

> Let me start off by saying that your intentions are very similar to mine.
> My OmniOS box is the storage backend for my household, and this includes
> MythTV as well as stackloads of photos, videos, music, etc.

Cool.

> Intel S2600CO Motherboard (16 x DIMM slots, dual LGA2011)

Interesting, although I don't like that "feature key". It sounds like it
has on-board SAS, but unless you type a magic "key" into the BIOS it
doesn't work? I hate that model. I'll have to take a look at the prices
though, the supermicro board was like $500.

> 8 x 16GB Hynix DDR ECC DIMMs (total 128GB)

Ouch, 16GB sticks? They were pretty pricy compared to the 8GB.

> 2 x LSI 9201-16i 6G SAS cards

Did you flash these with the IT firmware, or do they support JBOD out of
the box?

> Norco RPC-4224 case, 24 x hotswap 6G SAS bays

I looked at a couple Norco cases. They were OK, but the Supermicro one
just seemed better built, and

> OCZ ZX Series 850W power supply (note importantly this PSU has a 30A 5V
> rail)

came with dual redundant 960w power supplies. With the Norco cases, by
the time I added in the separately purchased power supplies, the cost
differential wasn't that much.

> 13 x 3TB WD Red drives
[...]
> With respect to the NAS drives - it's too early for me to give much
> feedback on them, but they are definitely the ones to get, for the reasons
> you gave.

My only concern is performance, given they're only 5400 RPM. I just
don't know how to qualify my I/O needs enough to tell if that'll be a
problem. How do you have them set up? The newegg reviews also have a lot
of people complaining about DOA or early death, so reliability is a
concern too. With a 3 year warranty, it's not too big a deal if a couple
go belly up, as long as it's not 3 in a row before the hot spare
resilvers 8-/. Have you run bonnie++ on your setup?

> 1. It's not going to work natively, nobody that I have been able to find
> has actually got a backend build working on Solaris and kept it up to date

Heh, I had no intention of trying to build Myth natively under illumos
:). That would just be painful.

> 2. It would have been a good option, but BrandZ has gone by the wayside
> long ago

You mean the linux compatible zone? That would have been interesting, at
least performance wise. I wonder how hard it would be to bring that back
to illumos.

> 3. KVM as I have so far tested has some major limitations that would make
> it impractical, i.e. both network bandwith and disk throughput is terrible
> to the point that it will cause problems with MythTV.

Really? I've got a quad-core sandy bridge i5 desktop set up at work
right now testing out omnios and kvm. It's only on a 100Mb port right
now, but a quick iperf from omnios native outbound:

[  4]  0.0-10.0 sec   106 MBytes  88.7 Mbits/sec
[  4]  0.0-10.0 sec  87.4 MBytes  73.3 Mbits/sec

Compared to one from a fedora vm under kvm:

[  3]  0.0-10.0 sec  91.8 MBytes  76.9 Mbits/sec
[  3]  0.0-10.0 sec  86.4 MBytes  72.4 Mbits/sec

Not a ridiculous difference. What kind of throughput are you seeing? Are
you using the e1000 nic or the virtio one? I'm using e1000 right now, I
haven't had a chance to play with the virtio. I won't be in the office
next week, but the week after I'll plug this box into a gig port and do
a bit more testing. Given joyent runs this stuff commercially, I can't
imagine it has endemic performance issues.

I'm actually planning to have my mythtv storage native on zfs, and share
via nfs from the host to the guest, so the vm disk won't really be an
issue for that.

> Please keep us up to date with how you go if you do deploy a MythTV backend
> into a KVM instance though, I'm interested to see your observations on
> network throughput, since mine was so crippled..

I probably won't get this box built or running before 2013 :), but I'll
definitely do some network testing on my omnios eval the week after next
and see what it does on a gig port.

Oh, forgot to try an iperf guest->host:

[  3]  0.0-10.0 sec   920 MBytes   772 Mbits/sec

Hmm, looks like my guest to host nfs should be pretty snappy :). I'd
expect higher though, I'll have to look at that.

Thanks for the feedback...

From denis at denisandyuki.net  Sun Nov 18 03:55:51 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Sun, 18 Nov 2012 19:55:51 +1100
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <20121118063332.GZ4175@bender.unx.csupomona.edu>
References: <50A7143C.2040002@acm.org>
	<CABOCf+joFjjqrC2LbP8mx014VCF5qHUhfT8u6aXyPvO_7xY_og@mail.gmail.com>
	<20121118063332.GZ4175@bender.unx.csupomona.edu>
Message-ID: <CABOCf+gZf_zEvALdijr9WRfYn5HPGLWf2gcDJnCTMMyxZBeGcA@mail.gmail.com>

On Sun, Nov 18, 2012 at 5:33 PM, Paul B. Henson <henson at acm.org> wrote:

> > Intel S2600CO Motherboard (16 x DIMM slots, dual LGA2011)
>
> Interesting, although I don't like that "feature key". It sounds like it
> has on-board SAS, but unless you type a magic "key" into the BIOS it
> doesn't work? I hate that model. I'll have to take a look at the prices
> though, the supermicro board was like $500.
>

It has on-board 3G SAS (not 6G), and it's 8 separate ports, so you need a
reverse-breakout connector to get it to work with a SFF-8087 connector ...
I don't like that configuration for a start.

To get it working, the "feature key" is actually a device you buy and plug
into a special header on the motherboard, not a serial number.

All that is moot anyway, since OmniOS / illumos does not support the SAS
chipset it uses anyway ...

So why bother, just use one / two of the many expansion slots on the mobo
with a tried and true SAS card ...

> 8 x 16GB Hynix DDR ECC DIMMs (total 128GB)
>
> Ouch, 16GB sticks? They were pretty pricy compared to the 8GB.
>

I had a special opportunity to purchase them in an auction down under at a
great price :)  Could have got 16 of them to fully populate the system, but
only running with 1 CPU atm it's a waste, and seriously do you need more
than 128GB ? :)


> > 2 x LSI 9201-16i 6G SAS cards
>
> Did you flash these with the IT firmware, or do they support JBOD out of
> the box?
>

These are non-RAID to begin with, they come with the IT firmware already.

These cards are really impressive, you can upgrade the firmware 'live' from
within Solaris, while you are still accessing the disks, with only about 15
seconds of downtime.

> Norco RPC-4224 case, 24 x hotswap 6G SAS bays
>
> I looked at a couple Norco cases. They were OK, but the Supermicro one
> just seemed better built, and
>

In Australia at least, the Supermicro are crazy-expensive.  The Norco are
incredibly cheap.  They're not 'amazingly' well made, but they are
perfectly fine build quality.  There's some minor silly design decisions,
but hey, it's 24 hotswappable 6G drive bays for $459 (AU$ / US$).


> > OCZ ZX Series 850W power supply (note importantly this PSU has a 30A 5V
> > rail)
>
> came with dual redundant 960w power supplies. With the Norco cases, by
> the time I added in the separately purchased power supplies, the cost
> differential wasn't that much.
>

Do your sums on each rail, you will probably not need a 960W, and dual
power supplies is probably an unnecessary expense in a home situation.  You
are probably better spending the money on a UPS ...

Note that the OCZ ZX power supply is only $175 (AU$ / US$).

How much is the Supermicro with only 16 drive bays?


> > 13 x 3TB WD Red drives
> [...]
> > With respect to the NAS drives - it's too early for me to give much
> > feedback on them, but they are definitely the ones to get, for the
> reasons
> > you gave.
>
> My only concern is performance, given they're only 5400 RPM. I just
> don't know how to qualify my I/O needs enough to tell if that'll be a
> problem.


These drives, in a single-drive config, easily do 100MBytes/sec sequential
each.  So 8 x 100Mbytes/sec = 800Mbytes/sec transfer rate in an 8-drive (+
parity) array.  Don't forget that gigabit ethernet is limited to best case
100Mbytes/sec.

Note that DVB video = maximum of 31.6Mbit/sec, i.e. 3.95Mbytes/sec so if
you have 6 concurrent streams you need 23.7Mbytes/sec which is still only a
quarter of the bandwidth of a single drive or a single gigabit connection.

With that many drives, you should be more concerned with power consumption
/ heat output control than throughput (IMHO).


> How do you have them set up?


I have 10 of them in a raidz2 (i.e. 8 x way data drives).  Arguably with
zfs it's best to have the data drives a as power of 2, i.e. 2, 4, 8, 16,
net of parity.  MythTV recordings are however on single drives - three
separate 3tb drives.  A friend of mine is trying to convince me otherwise,
however ... and to pool the recordings into the main 24TB 10-drive array.


> The newegg reviews also have a lot
> of people complaining about DOA or early death, so reliability is a
> concern too.


I bought 6 of them about 2 months ago, no DOA, and have now bought 13 for
myself, no issues with any of them.  There are still another 2 not yet
installed.

Just bear in mind that:
1. For every 1 person complaining, there are probably 50 people who had no
issues.
2. There are now only 2 hard disk manufacturers left in the entire world,
WD and Seagate.  Seagate has a 1 year warranty and no comparable product to
the WD Red drives.  'nuff said.


> With a 3 year warranty, it's not too big a deal if a couple
> go belly up, as long as it's not 3 in a row before the hot spare
> resilvers 8-/. Have you run bonnie++ on your setup?
>

No, but that's one of the reasons why I am a big advocate for 2-drive
parity in all arrays with a large number of drives.


> > 2. It would have been a good option, but BrandZ has gone by the wayside
> > long ago
>
> You mean the linux compatible zone? That would have been interesting, at
> least performance wise. I wonder how hard it would be to bring that back
> to illumos.
>

There were probably some significant compatibility issues that justified
the termination of the project that I'm not aware of ...


> > 3. KVM as I have so far tested has some major limitations that would make
> > it impractical, i.e. both network bandwith and disk throughput is
> terrible
> > to the point that it will cause problems with MythTV.
>
> Really?


Major limitations for me ... but it's been a while since I tested.  You can
probably find the results of my iperf tests in old posts on this mailing
list.  I've been told that these have been fixed in the build released a
couple of weeks ago - I've yet to verify it yet.


> What kind of throughput are you seeing?


Sub-100Mbit speeds on a VM that was connected to native dual gigabit ports
in the host.


> Are you using the e1000 nic or the virtio one?


Tried both, no difference.


> Given joyent runs this stuff commercially, I can't imagine it has endemic
> performance issues.
>

Not necessarily ... Most Joyent cloud connectivity is 'internet facing' not
high speed LAN.  If the internet-facing connectivity is limited to 100mbit
is anybody going to notice much?

I tried SmartOS without any happiness.  I'm really happy with the network
connectivity setup / control from Solaris.  It's really flexible, you can
do almost anything with it and Crossbow.  Suddenly with SmartOS, you are
dropped back to a dumb configuration file that's worse than Linux of more
than 15-years ago ... no VLAN configuration, no bonding / link aggregation,
no nothing ... it was horrible.  You can configure up all the network
interfaces using the standard Solaris commands, but it will lose the lot on
the next reboot.  I found this really incredibly frustrating.

Any way in my experience with KVM under OmniOS, I had two major issues with
network connectivity:  I was trying to mount an 8-drive ZFS array over
iSCSI from the KVM client (Solaris 11) to the host (OmniOS).  The drives
were shared out from their raw rdsk devices.  However the connectivity was
simply not there - it just kept timing out and it died ... would never
properly mounted anything.  It seems likely that the root cause of this
issue was the duplicate packet bug that was fixed a couple of weeks ago.

The second issue was in throughput - 100mbit in real throughput for iSCSI
is really bad, gigabit is a bare minimum, 10G is really required (but who
can afford that for home).

I'm actually planning to have my mythtv storage native on zfs, and share
> via nfs from the host to the guest, so the vm disk won't really be an
> issue for that.
>

NFS still goes over the ethernet connectivity, and despite being host-VM
native and should not go through the hardware, it was still far less than
gigabit throughput, when I would expect it to exceed gigabit ...

You could set up an entirely different subnet with an etherstub that was
not connected to real hardware, but that just seems like a horribly complex
workaround to get around a bug that should not exist in the first place ...
and it may not even fix it, because the VM ethernet throughput bug seemed
to be more complex than just that ...

Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121118/3c42f462/attachment.html>

From henson at acm.org  Sun Nov 18 21:20:36 2012
From: henson at acm.org (Paul B. Henson)
Date: Sun, 18 Nov 2012 18:20:36 -0800
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <CABOCf+gZf_zEvALdijr9WRfYn5HPGLWf2gcDJnCTMMyxZBeGcA@mail.gmail.com>
References: <50A7143C.2040002@acm.org>
	<CABOCf+joFjjqrC2LbP8mx014VCF5qHUhfT8u6aXyPvO_7xY_og@mail.gmail.com>
	<20121118063332.GZ4175@bender.unx.csupomona.edu>
	<CABOCf+gZf_zEvALdijr9WRfYn5HPGLWf2gcDJnCTMMyxZBeGcA@mail.gmail.com>
Message-ID: <20121119022036.GD4175@bender.unx.csupomona.edu>

On Sun, Nov 18, 2012 at 07:55:51PM +1100, Denis Cheong wrote:

> To get it working, the "feature key" is actually a device you buy and plug
> into a special header on the motherboard, not a serial number.

Meh, it still doesn't actually supply any actual functionality other
than "enabling" circuitry already on the board, right? I'm not sure if
they're still up to it, but remember a couple years ago when Intel was
selling "upgrade cards" with a magic code you could type in to the BIOS
and it would enable higher performance on the Pentium CPU already in it?
I just don't like that model :(.

> So why bother, just use one / two of the many expansion slots on the mobo
> with a tried and true SAS card ...

Hmm, looks like that Intel board runs over $600 around here, more than
the Supermicro I was already looking at (which has 8 LSI SAS ports
already on board (with no magic "upgrade" required)).

> Do your sums on each rail, you will probably not need a 960W, and dual
> power supplies is probably an unnecessary expense in a home situation.

Dude -- this *whole box* is an unnecessary expense in a home situation
;). I don't really want to have downtime if a power supply blows, and I
particularly don't want to have to open up the case and rip out /
reconnect a bunch of cables to replace it. The relatively low
incremental cost of dual redundants will be more than recouped in saved
frustration.

> You are probably better spending the money on a UPS ...

I already have 2 1500VA UPS's in my rack, one for each power supply :).

> Note that the OCZ ZX power supply is only $175 (AU$ / US$).
> 
> How much is the Supermicro with only 16 drive bays?

About $1000. If you got dual rendundant supplies for your Norco, I bet
it would have come close to that. More bays, yes, but I'm already buying
too many hard drives, I wouldn't want to be tempted to buy more...

> These drives, in a single-drive config, easily do 100MBytes/sec sequential
> each.  So 8 x 100Mbytes/sec = 800Mbytes/sec transfer rate in an 8-drive (+
> parity) array.

That's streaming; if you're running a lot of vm's doing different stuff,
you also have to worry about random IO, a given raidz vdev only provides
the performance of one drive in that scenario. If I go with 2 x 6 disk
raidz2, I'll have 8 data drives, and two vdevs. No idea how that'll work
out for my use case, guess I'll just have to cross my fingers and see.

> Note that DVB video = maximum of 31.6Mbit/sec, i.e. 3.95Mbytes/sec so if

In the US, an ATSC OTA stream maxes out at 19.39Mb/s, so my utilization
for a given number of streams will be less than yours.

> With that many drives, you should be more concerned with power consumption
> / heat output control than throughput (IMHO).

Yah. That's why the red drives seem appealing.

> I have 10 of them in a raidz2 (i.e. 8 x way data drives).  Arguably with

That's big for a raidz2.

> net of parity.  MythTV recordings are however on single drives - three
> separate 3tb drives.  A friend of mine is trying to convince me otherwise,
> however ... and to pool the recordings into the main 24TB 10-drive array.

You don't care if you lose your recordings if a disk blows up? That's
really the deciding point. I don't really want to lose mine, I already
lost two year's worth once when a linux software raid blew up after a
sata controller failure.

> I bought 6 of them about 2 months ago, no DOA, and have now bought 13 for
> myself, no issues with any of them.  There are still another 2 not yet
> installed.
[...]
> 1. For every 1 person complaining, there are probably 50 people who had no
> issues.

I was going to say exactly that :). But still, there were even more DOA
complaints than usual in a hard drive review.

> No, but that's one of the reasons why I am a big advocate for 2-drive
> parity in all arrays with a large number of drives.

Assuming you have a hot spare, my understanding of the cutover point
from raidz to raidz2 is the liklihood of a fatal bit error while
resilvering. The bigger the drives, the more likely the failure, so when
you're talking 2, 3 or even 4TB drives now I think raidz2 is recommended
even with a small number of drives.

> Sub-100Mbit speeds on a VM that was connected to native dual gigabit ports
> in the host.

Hmm. I'm almosted tempted to go into work on my vacation week to cut my
test box over to a gig port to see what happens :).

So what switch was on the other side of the aggregation? Port
aggregation can be pretty flaky sometimes :(. I had an openbsd box
recently that I was trying to bind two gig links together to a Cisco
switch, when both were hot there was a crapload of latency and packet
drop. Pull either one, worked fine. Never did figure that out, ran of
time and just left it on one link.

> Not necessarily ... Most Joyent cloud connectivity is 'internet facing' not
> high speed LAN.  If the internet-facing connectivity is limited to 100mbit
> is anybody going to notice much?

True. But I'd think for some of the internet facing infrastructure,
there'd be datacenter local stuff going on, database replication,
whatever. Plus the joyent crew seems pretty analytical, I think they'd
have tested throughput and looked into any problems they found.

> no nothing ... it was horrible.  You can configure up all the network
> interfaces using the standard Solaris commands, but it will lose the lot on
> the next reboot.  I found this really incredibly frustrating.

Yah, I looked at smartos too. I really want to customize the global zone
though, pretty much required for NFS/CIFS service, so it got ruled out.

> properly mounted anything.  It seems likely that the root cause of this
> issue was the duplicate packet bug that was fixed a couple of weeks ago.

I think I saw that. It wasn't actually "fixed", right, so much as worked
around? They're dropping the duplicate packets but still aren't sure
where/why they're happening.

> NFS still goes over the ethernet connectivity, and despite being host-VM
> native and should not go through the hardware, it was still far less than
> gigabit throughput, when I would expect it to exceed gigabit ...

Hmm, my quick guest to host test showed over 700Mb/s. With a virtual
e1000, it might be limited to gigabit no matter what, since it's
pretending to be a gig card. The vmxnet3 driver in esx claims to be a
10G card. I'm not sure what virtio reports to the OS, I haven't tried it
yet.

From henson at acm.org  Sun Nov 18 21:30:44 2012
From: henson at acm.org (Paul B. Henson)
Date: Sun, 18 Nov 2012 18:30:44 -0800
Subject: [OmniOS-discuss] no headers in default install?
Message-ID: <20121119023044.GE4175@bender.unx.csupomona.edu>

On the current stable, it looks like the compiler is part of the default
install, but not header files or utilities like ar?

>From a minimization perspective, I guess I could see not including any
dev tools as part of the base install, but including a compiler but not
the pieces that make it work seems inconsistent.

What are thoughts on including dev tools in the base install? If it's a
yes, maybe the other pieces could come along for the ride? If a no,
perhaps the compiler should be pulled out to decrease confusion? If the
latter, it would be nice to have a meta package that pulls everything in
(maybe there already is one)? So far I've installed system/header,
math/header-math, and developer/object-file to get something compiled,
I'm probably still missing pieces that nothings needed yet :).

Thanks...


From henson at acm.org  Sun Nov 18 22:10:49 2012
From: henson at acm.org (Paul B. Henson)
Date: Sun, 18 Nov 2012 19:10:49 -0800
Subject: [OmniOS-discuss] [smartos-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <50A88DE7.90202@ianshome.com>
References: <50A7143C.2040002@acm.org>
 <50A88DE7.90202@ianshome.com>
Message-ID: <20121119031027.GA14994@bender.unx.csupomona.edu>

On Sun, Nov 18, 2012 at 08:27:35PM +1300, Ian Collins wrote:

> that, unlike those on Dell PERCs,  the 2308 hasn't been hobbled to 
> prevent JBOD mode.  So as long as the recently added driver sees the 
> card, you can use the megaCLI utility to enable it.
> 
> The on board SATA works fine and you shouldn't have any problems with 
> the i350.

Cool, thanks for the positive feedback.

> I use an LSI 2911 which uses the well supported 2008 chip.

Hmm, I don't see any of those for sale, and google's not being much
help. Is that an older card? Maybe it's been discontinued and replaced
with a new model.

> I'm happy with WD (non-RAID) blacks for a home system.  As long as your 
> case has good cooling on the drives, they'll be fine.

The case I'm looking at has 4 80mm fans midplane, so there should be
decent ventilation.

> I used a couple of Crucial M4 drives for the ARC and Intel 311s for the ZIL.

Looks like the 311 is EOL, replaced by the 313. SLC flash for
durability, nice, but I couldn't find anything that says whether or not
the 313 has a supercapacitor to flush the write cache on unexpected
power failure.

Thanks much for the input...

From esproul at omniti.com  Mon Nov 19 10:11:16 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 19 Nov 2012 10:11:16 -0500
Subject: [OmniOS-discuss] no headers in default install?
In-Reply-To: <20121119023044.GE4175@bender.unx.csupomona.edu>
References: <20121119023044.GE4175@bender.unx.csupomona.edu>
Message-ID: <CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>

On Sun, Nov 18, 2012 at 9:30 PM, Paul B. Henson <henson at acm.org> wrote:
> On the current stable, it looks like the compiler is part of the default
> install, but not header files or utilities like ar?
>
> From a minimization perspective, I guess I could see not including any
> dev tools as part of the base install, but including a compiler but not
> the pieces that make it work seems inconsistent.

No dev tools are supposed to be installed by default.  It looks like
we picked up this dependency via some of the illumos-gate packages:

$ pkg search -H -r -o pkg.name 'depend::developer/gcc44'
system/library/storage/fibre-channel/libsun_fc
system/fru-id
system/management/intel-amt
service/network/nis
system/network/nis
audio/audio-utilities

A spot-check of some of these packages shows that it's
libgcc_s/libstdc++ that is causing the dependency.  Those are supposed
to come from system/library/gcc-4-runtime and
system/library/g++-4-runtime, respectively.  My guess is that
pkgdepend incorrectly identified the dependencies for these packages.
We'll need to dig a bit more, but I imagine we'll be able to fix this
by updating the dependency in the existing packages (I don't think
we'll actually need to re-roll anything.)


>
> What are thoughts on including dev tools in the base install? If it's a
> yes, maybe the other pieces could come along for the ride? If a no,
> perhaps the compiler should be pulled out to decrease confusion? If the
> latter, it would be nice to have a meta package that pulls everything in
> (maybe there already is one)? So far I've installed system/header,
> math/header-math, and developer/object-file to get something compiled,
> I'm probably still missing pieces that nothings needed yet :).

I don't think dev tools belong in a default install, but it should be
easier to obtain the basics.  As a reference the omnios-build system
has a list in the BasicRequirements() function:

http://omnios.omniti.com/file.php/core/omnios-build/lib/functions.sh?rev=7949acbf16edfb6d09efd339b426c455d30c14dc&jump=branch%3Ar151004#l150

We could do a "convenience package" that would pull in all the right
things to make it easier to get started.  Would that meet your needs?

Eric

From esproul at omniti.com  Mon Nov 19 11:38:56 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 19 Nov 2012 11:38:56 -0500
Subject: [OmniOS-discuss] no headers in default install?
In-Reply-To: <CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
References: <20121119023044.GE4175@bender.unx.csupomona.edu>
	<CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
Message-ID: <CA+QY2RQMQxkiP5UxVTFJfkN_ZON_ZD_v1y3-iDj1_O8bBP-HJg@mail.gmail.com>

On Mon, Nov 19, 2012 at 10:11 AM, Eric Sproul <esproul at omniti.com> wrote:
> We'll need to dig a bit more, but I imagine we'll be able to fix this
> by updating the dependency in the existing packages (I don't think
> we'll actually need to re-roll anything.)

FYI, I've opened http://omnios.omniti.com/ticket.php/42 to track this work.

Hopefully that will be the answer to life, the universe and everything.  ;)

Eric

From esproul at omniti.com  Mon Nov 19 15:07:29 2012
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 19 Nov 2012 15:07:29 -0500
Subject: [OmniOS-discuss] no headers in default install?
In-Reply-To: <CA+QY2RQMQxkiP5UxVTFJfkN_ZON_ZD_v1y3-iDj1_O8bBP-HJg@mail.gmail.com>
References: <20121119023044.GE4175@bender.unx.csupomona.edu>
	<CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
	<CA+QY2RQMQxkiP5UxVTFJfkN_ZON_ZD_v1y3-iDj1_O8bBP-HJg@mail.gmail.com>
Message-ID: <CA+QY2RQg=31nSUz+XpjrmoP9Y7LosmV6xES-Jbg-z308yZnGUw@mail.gmail.com>

Paul,
Something else I neglected to mention earlier is that the gcc44
package probably isn't what you want for general development anyway.
We have gcc46 in r151004 and gcc47 in bloody.

Regarding the dependency issue, I posted some comments in
http://omnios.omniti.com/ticket.php/42#1493 .  Theo found that the
master makefiles  are hard-coding runpaths for libstdc++ which is the
source of the dependency.  Unfortunately the fix is too disruptive to
backport to r151004, but it should be fixed soon in bloody.  The fix
will probably also remain private to OmniOS, as the runpaths are
necessary for other distros that don't ship libstdc++.so.6.0.13 in
/usr.

Eric

From peter at psych.columbia.edu  Tue Nov 20 09:04:10 2012
From: peter at psych.columbia.edu (Peter Tripp)
Date: Tue, 20 Nov 2012 09:04:10 -0500
Subject: [OmniOS-discuss] no headers in default install?
In-Reply-To: <CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
References: <20121119023044.GE4175@bender.unx.csupomona.edu>
	<CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
Message-ID: <0D3A8D60-81D0-470B-B493-8A515EC75D58@psych.columbia.edu>

On Nov 19, 2012, at 10:11 AM, Eric Sproul wrote:
> 
> We could do a "convenience package" that would pull in all the right
> things to make it easier to get started.  Would that meet your needs?

Eric, I think this is a good idea, like the 'build-essential' metapackage in Ubuntu it gives people a single thing to install when compiling something for the first time.  I understand (and appreciate) taking the time to keep the build tools out of the base install to keep production images small, but it should also be similarly straightforward to install the standard build tools when you need them.

Thanks
-Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121120/798e305e/attachment.html>

From sqmishra at gmail.com  Wed Nov 21 00:19:33 2012
From: sqmishra at gmail.com (Samir Mishra)
Date: Wed, 21 Nov 2012 10:49:33 +0530
Subject: [OmniOS-discuss] OmniOS Bloody in KVM on OmniOS Stable Gobal
Message-ID: <CAHDYqcoSg24i4eHfWqMu0S3BSK-2BpzSD3eX7F4+62tcLMpVTA@mail.gmail.com>

Hello.

I'd like to set up an instance of OmniOS Bloody in a KVM with the global
zone being managed by OmniOS Stable. I'd also like to provision the KVM
with access to a raw disk.

I'd like to set up a zpool on the raw disk to be managed by the KVM. Is
this possible/practical?

I'm new to Solaris, so if anyone has done anything similar, I would
appreciate any input I can get to help me get started.

Thanks in advance.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121121/2d60736a/attachment.html>

From esproul at omniti.com  Wed Nov 21 10:22:52 2012
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 21 Nov 2012 10:22:52 -0500
Subject: [OmniOS-discuss] OmniOS Bloody in KVM on OmniOS Stable Gobal
In-Reply-To: <CAHDYqcoSg24i4eHfWqMu0S3BSK-2BpzSD3eX7F4+62tcLMpVTA@mail.gmail.com>
References: <CAHDYqcoSg24i4eHfWqMu0S3BSK-2BpzSD3eX7F4+62tcLMpVTA@mail.gmail.com>
Message-ID: <CA+QY2RRk1PdqggwZf_6xLgboLQr2sNjTQod-FBfcR-wj+QvoEw@mail.gmail.com>

On Wed, Nov 21, 2012 at 12:19 AM, Samir Mishra <sqmishra at gmail.com> wrote:
> Hello.
>
> I'd like to set up an instance of OmniOS Bloody in a KVM with the global
> zone being managed by OmniOS Stable. I'd also like to provision the KVM with
> access to a raw disk.
>
> I'd like to set up a zpool on the raw disk to be managed by the KVM. Is this
> possible/practical?
>
> I'm new to Solaris, so if anyone has done anything similar, I would
> appreciate any input I can get to help me get started.

Hi Samir,
What you propose should work.  I haven't used raw host drives myself
(we usually give a zvol from the host as the guest's disk) but I
believe you would just use the host device path, e.g. /dev/dsk/c*t*d*)
instead of the path to a file as the value of "file=" in the -drive
option.  You won't need to set up a zpool on the raw disk from the
host's point of view.  The guest will set up its own zpool on the
device it sees.

The only caveat I'd say would be to ensure that you can give the guest
at least 4GB of RAM.  ZFS loves RAM, so get as much as you can afford
in the host system.

Hope this helps,
Eric

From henson at acm.org  Wed Nov 21 22:15:53 2012
From: henson at acm.org (Paul B. Henson)
Date: Wed, 21 Nov 2012 19:15:53 -0800
Subject: [OmniOS-discuss] no headers in default install?
In-Reply-To: <CA+QY2RQg=31nSUz+XpjrmoP9Y7LosmV6xES-Jbg-z308yZnGUw@mail.gmail.com>
References: <20121119023044.GE4175@bender.unx.csupomona.edu>
	<CA+QY2RSs3YRB7wpX_a7to918KpVEUpmgLkFgLmEnCQT4h2S2Kw@mail.gmail.com>
	<CA+QY2RQMQxkiP5UxVTFJfkN_ZON_ZD_v1y3-iDj1_O8bBP-HJg@mail.gmail.com>
	<CA+QY2RQg=31nSUz+XpjrmoP9Y7LosmV6xES-Jbg-z308yZnGUw@mail.gmail.com>
Message-ID: <20121122031553.GR4175@bender.unx.csupomona.edu>

On Mon, Nov 19, 2012 at 03:07:29PM -0500, Eric Sproul wrote:

> I don't think dev tools belong in a default install, but it should be
> easier to obtain the basics.

That works for me, it was just confusing to find a compiler and then
have it not work. If I recall correctly, I had to explicitly install the
linker package in the previous omnios release, but it was already there
on this one. Was that included unintentionally too?

> As a reference the omnios-build system has a list in the
> BasicRequirements() function:
[...]
> We could do a "convenience package" that would pull in all the right
> things to make it easier to get started.  Would that meet your needs?

That might be useful, although it's not a particularly long list, and
just documenting it on the wiki might be enough.

> FYI, I've opened http://omnios.omniti.com/ticket.php/42 to track this
> work.

Cool. This one's about resolved, but for future reference is there any
way to add yourself (as an omnios user) to the CC on a ticket to watch
it?

> Hopefully that will be the answer to life, the universe and
> everything.  ;)

Only if the question is "How many roads must a man walk down" :).

> Something else I neglected to mention earlier is that the gcc44
> package probably isn't what you want for general development anyway.

I was just trying to get iperf built for some quick kvm throughput
testing, 4.4 did the job. I'll install the latest version before I build
anything serious, thanks.

> source of the dependency.  Unfortunately the fix is too disruptive to
> backport to r151004, but it should be fixed soon in bloody.

Hmm, I'll probably be using bloody again soon, after I build my
virtualization box I'm going to want joyent's apix fix for sandy bridge:

https://github.com/joyent/illumos-joyent/commit/4d86fb7f59410be72e467483b74e2eebff6052b2

which I believe recently made its way into illumos-gate. I'll also want
aclmode=restricted support on my box (if only for hubris) before six
months go by ;)...

> The fix will probably also remain private to OmniOS, as the runpaths
> are necessary for other distros that don't ship libstdc++.so.6.0.13 in
> /usr.

Interesting. gcc isn't in illumos-gate, so ips makes a dependency on a
package installed on the host building it? That seems kludgy. I vaguely
recall seeing some discussion about C++ runtimes on illumos-discuss, but
don't think it went anywhere. Maybe I'll dig through the archives to
refresh my memory and bring it back up.

Thanks for the quick answers and updates...

From john at firecrest.eclipse.co.uk  Fri Nov 23 16:26:09 2012
From: john at firecrest.eclipse.co.uk (John Ratcliffe)
Date: Fri, 23 Nov 2012 21:26:09 +0000
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <50A7143C.2040002@acm.org>
References: <50A7143C.2040002@acm.org>
Message-ID: <50AFE9F1.7050300@firecrest.eclipse.co.uk>

I followed your recent thread with interest. My response is a bit 
delayed because I have been busy being ill for the last few weeks.

Like you, I am interested in setting up a "proper" media server.

I am considering putting in some serious effort to get to grips with 
OmniOS so I can use it as my server platform. For a couple of reasons. I 
like the minimalist approach. I have been away from the SunOS/Solaris 
arena for 25 years, but I like what I see, particularly ZFS.

> I think I'm finally going to get around to putting together the 
> illumos home/hobby server I've been thinking about for the past few 
> years :), and would appreciate a little feedback on 
> parts/compatibility/design.
So would I. :)

> The box is intended to be both a storage server (music/video/etc 
> media, documents, whatever) with content available via both NFS and 
> CIFS, as well as a virtualization server using kvm to run some number 
> of linux instances (the most heavyweight of which will probably be the 
> mythtv instance, but there will be a number of other miscellaneous 
> things going on). I'm thinking of using two SSD's with a partition 
> mirrored for rpool, a 2nd separate partition as L2ARC on each, and 
> possibly a third mirrored for slog (or potentially a separate SSD just 
> for slog), and a storage pool consisting of 2 6 disk raidz2 vdevs.
Thanks for pointing me at MythTV. I haven't encountered this before. Is 
this unsupported on the OpenSolaris family? Is that why you propose 
using linux?

If you can't use OmniOS for everything, would it not be better to use 
linux as the host OS when using KVM? I haven't done any benchmarking 
yet, but my understanding is that KVM "works best" with linux (whatever 
"works best" really means)?

There seems to be an Arch linux distro that is specifically for MythTV 
support. Was this the kind of install for MythTV you had in mind?

http://www.mythtv.org/wiki/MythTV_distros
https://wiki.archlinux.org/index.php/MythTV

> For the motherboard, I'm looking at the Supermicro X9DRD-7LN4F-JBOD, 
> which is a dual LGA 2011 socket board with 16 DIMM slots, 2 x SATA3, 4 
> x SATA2, and 8 x SAS (LSI 2308 controller onboard) along with 4 intel 
> i350 based gig nics. My understanding is that illumos is perfectly 
> happy with the LSI 2308 in IT hell). It also looks like illumos works 
> with the intel i350 gig nics, and I assume there should be no issue 
> with the onboard Intel AHCI SATA controller?
You talk about illumos. Is this your preferred platform rather than OmniOS?

 From the googling I have done about the OpenSolaris family it looks 
like Intel NICs are the most reliable choice. Do you agree?

I haven't gone into any details yet. It looks like I won't be building 
it until next year. But thanks for a few ideas.

I will reread the thread again. I think Denis may have answered some of 
my questions. Any feedback is still appreciated.


John


From henson at acm.org  Fri Nov 23 19:06:09 2012
From: henson at acm.org (Paul B. Henson)
Date: Fri, 23 Nov 2012 16:06:09 -0800
Subject: [OmniOS-discuss] hardware specs for illumos
 storage/virtualization server
In-Reply-To: <50AFE9F1.7050300@firecrest.eclipse.co.uk>
References: <50A7143C.2040002@acm.org>
	<50AFE9F1.7050300@firecrest.eclipse.co.uk>
Message-ID: <20121124000609.GU4175@bender.unx.csupomona.edu>

On Fri, Nov 23, 2012 at 09:26:09PM +0000, John Ratcliffe wrote:

> Thanks for pointing me at MythTV. I haven't encountered this before. Is 
> this unsupported on the OpenSolaris family? Is that why you propose 
> using linux?

It would probably be difficult to get it working under Solaris. There
are windows and mac os x ports, but the primary development is under
Linux.
 
> If you can't use OmniOS for everything, would it not be better to use 
> linux as the host OS when using KVM? I haven't done any benchmarking 
> yet, but my understanding is that KVM "works best" with linux (whatever 
> "works best" really means)?

Before joyent ported kvm, I was originally planning on having a zfs
storage server and a separate linux kvm virtualization server. It would
be nice to combine them for efficiency and cost savings. kvm is
developed under Linux, so that platform will indeed have the latest
features and possibly performance. OTOH, zfs under linux is still a bit
immature. It's a trade-off, the final outcome of which I haven't yet
determined.

> There seems to be an Arch linux distro that is specifically for MythTV 
> support. Was this the kind of install for MythTV you had in mind?

I current run myth under Gentoo, which is my intended kvm guest too.

> You talk about illumos. Is this your preferred platform rather than OmniOS?

illumos is the base OS underlying omnios, open indiana, smartos, etc.
It's not really suitable for deployment on its own, but is extended and
packaged by various distributions based on it. Many implementation details
can be shared across distributions, and I tend to refer to "illumos"
when discussings things like hardware support, and only to a specific
distribution when discussings particulars of that distribution.

> From the googling I have done about the OpenSolaris family it looks 
> like Intel NICs are the most reliable choice. Do you agree?

Probably. They're likely the most common in server class hardware.

From stephen at atalanta-systems.com  Tue Nov 27 08:29:29 2012
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Tue, 27 Nov 2012 13:29:29 +0000
Subject: [OmniOS-discuss] DL385G1
Message-ID: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>

Hi chaps,

Just attempted to install OmniOS 'stable' ontp a DL385G1.  Yes, I know
it's old, but it's the test kit the client has.  Being on the Solaris
HCL, I hoped it'd work just fine on OmniOS, but I get a kernel panic
on install.  Afraid it restarts too quickly for me to read, and I
don't have a camera/phone with me today, but just a heads up.  has
anyone else got this working?  Worth trying bloody instead?

Will follow up with details and a picture as soon as I can.

S.

-- 
Stephen Nelson-Smith,
Founder, Principal Consultant,
Atalanta Systems Ltd,
Web: http://agilesysadmin.net
Twitter: @lordcope
Skype: atalanta.systems
Direct: +44 (0) 1329 550203
Mobile: +44 (0) 7917 101919

Atalanta Systems: The Agile Infrastructure Enablers
http://atalanta-systems.com

From aszeszo at gmail.com  Tue Nov 27 08:42:50 2012
From: aszeszo at gmail.com (Andrzej Szeszo)
Date: Tue, 27 Nov 2012 14:42:50 +0100
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
Message-ID: <F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>

Hi Stephen

What you are seeing could be due to cpqary3 driver not working well. Try booting with -B disable-cpqary3=true to confirm. The system should boot but will not detect the disks.

Cheers,

Andrzej

On 27 Nov 2012, at 14:29, Stephen Nelson-Smith <stephen at atalanta-systems.com> wrote:

> Hi chaps,
> 
> Just attempted to install OmniOS 'stable' ontp a DL385G1.  Yes, I know
> it's old, but it's the test kit the client has.  Being on the Solaris
> HCL, I hoped it'd work just fine on OmniOS, but I get a kernel panic
> on install.  Afraid it restarts too quickly for me to read, and I
> don't have a camera/phone with me today, but just a heads up.  has
> anyone else got this working?  Worth trying bloody instead?
> 
> Will follow up with details and a picture as soon as I can.
> 
> S.
> 
> -- 
> Stephen Nelson-Smith,
> Founder, Principal Consultant,
> Atalanta Systems Ltd,
> Web: http://agilesysadmin.net
> Twitter: @lordcope
> Skype: atalanta.systems
> Direct: +44 (0) 1329 550203
> Mobile: +44 (0) 7917 101919
> 
> Atalanta Systems: The Agile Infrastructure Enablers
> http://atalanta-systems.com
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From stephen at atalanta-systems.com  Tue Nov 27 08:54:19 2012
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Tue, 27 Nov 2012 13:54:19 +0000
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
Message-ID: <CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>

Hi Andrzej,

On 27 November 2012 13:42, Andrzej Szeszo <aszeszo at gmail.com> wrote:
> Hi Stephen
>
> What you are seeing could be due to cpqary3 driver not working well. Try booting with -B disable-cpqary3=true to confirm. The system should boot but will not detect the disks.

That seems to have worked... the system has booted.

S.

From stephen at atalanta-systems.com  Tue Nov 27 10:11:53 2012
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Tue, 27 Nov 2012 15:11:53 +0000
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
Message-ID: <CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>

Hi,

On 27 November 2012 13:54, Stephen Nelson-Smith
<stephen at atalanta-systems.com> wrote:

>> What you are seeing could be due to cpqary3 driver not working well. Try booting with -B disable-cpqary3=true to confirm. The system should boot but will not detect the disks.
>
> That seems to have worked... the system has booted.

So, what's the recommendation?  The latest driver from HP seems to be
2.2.0, and this seems to match what is shipped with OmniOS.  I think
I'll try an older version... but if anyone's got this to work and can
recommend a version / approach, I'd be grateful.

Thanks.

S.

From stephen at atalanta-systems.com  Tue Nov 27 10:42:39 2012
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Tue, 27 Nov 2012 15:42:39 +0000
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
	<CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
Message-ID: <CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>

Hi,

On 27 November 2012 15:11, Stephen Nelson-Smith
<stephen at atalanta-systems.com> wrote:

> So, what's the recommendation?  The latest driver from HP seems to be
> 2.2.0, and this seems to match what is shipped with OmniOS.  I think
> I'll try an older version... but if anyone's got this to work and can
> recommend a version / approach, I'd be grateful.

For reference:

rem_drv cpqary3
rm -rf /var/sadm/pkg/CPQary3
find /kernel -name cpqary\* -exec rm {} \+
wget ftp://ftp.hp.com/pub/softlib2/software1/pubsw-windows/p1220948930/v80737/CPQary3-2.5.1-solaris10-i386.tar.gz
tar xvvf CPQary3-2.5.1-solaris10-i386.tar.gz
pkgadd -d CPQary3-2.5.1-solaris10-i386/CPQary3.pkg
# iostat -En
c1t0d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: HL-DT-ST Product: DVDRAM GP10NB20  Revision: 1.01 Serial No:
Size: 0.38GB <384073728 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0
c2t0d0           Soft Errors: 0 Hard Errors: 5 Transport Errors: 0
Vendor: TSSTcorp Product: CD-ROM  TS-L162C Revision: N204 Serial No:
Size: 0.00GB <0 bytes>
Media Error: 0 Device Not Ready: 5 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0
c3t0d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: HP       Product: LOGICAL VOLUME   Revision: 1.92 Serial No:
Size: 293.62GB <293621850112 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0
c3t1d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: HP       Product: LOGICAL VOLUME   Revision: 1.92 Serial No:
Size: 146.80GB <146803752960 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

S.

From esproul at omniti.com  Tue Nov 27 12:31:52 2012
From: esproul at omniti.com (Eric Sproul)
Date: Tue, 27 Nov 2012 12:31:52 -0500
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
	<CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
	<CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
Message-ID: <CA+QY2RSvx7f6k2QdjKjCOxixUcUi+P=juM9npZ3d0Wj12HzWEw@mail.gmail.com>

On Tue, Nov 27, 2012 at 10:42 AM, Stephen Nelson-Smith
<stephen at atalanta-systems.com> wrote:
> wget ftp://ftp.hp.com/pub/softlib2/software1/pubsw-windows/p1220948930/v80737/CPQary3-2.5.1-solaris10-i386.tar.gz

That's good to know.  The cpqary3 driver comes from the closed-bins
collection that gets added to illumos-gate during the build process
(on-closed-bins-nd.i386.tar.bz2).  Note the "nd" there-- supposedly
these are non-distributable, but AFAIK *we've* received them legally.
The HP standard EULA forbids distribution of their drivers, though, so
I've emailed them to ask permission to distribute the latest cpqary3.

Until we hear otherwise, your method looks like a good workaround if
one cannot or wishes not to use an add-in HBA that is better
supported.  It would be awesome if you could document it on the wiki.

Thanks,
Eric

From aszeszo at gmail.com  Wed Nov 28 03:25:53 2012
From: aszeszo at gmail.com (Andrzej Szeszo)
Date: Wed, 28 Nov 2012 09:25:53 +0100
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
	<CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
	<CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
Message-ID: <AAD6EACE-5207-48B8-9CEC-DF0AFD40380A@gmail.com>

Hi Stephen

Did you manage to get installed system booting fine with the updated driver then?

Cheers,

Andrzej

On 27 Nov 2012, at 16:42, Stephen Nelson-Smith <stephen at atalanta-systems.com> wrote:

> Hi,
> 
> On 27 November 2012 15:11, Stephen Nelson-Smith
> <stephen at atalanta-systems.com> wrote:
> 
>> So, what's the recommendation?  The latest driver from HP seems to be
>> 2.2.0, and this seems to match what is shipped with OmniOS.  I think
>> I'll try an older version... but if anyone's got this to work and can
>> recommend a version / approach, I'd be grateful.
> 
> For reference:
> 
> rem_drv cpqary3
> rm -rf /var/sadm/pkg/CPQary3
> find /kernel -name cpqary\* -exec rm {} \+
> wget ftp://ftp.hp.com/pub/softlib2/software1/pubsw-windows/p1220948930/v80737/CPQary3-2.5.1-solaris10-i386.tar.gz
> tar xvvf CPQary3-2.5.1-solaris10-i386.tar.gz
> pkgadd -d CPQary3-2.5.1-solaris10-i386/CPQary3.pkg
> # iostat -En
> c1t0d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
> Vendor: HL-DT-ST Product: DVDRAM GP10NB20  Revision: 1.01 Serial No:
> Size: 0.38GB <384073728 bytes>
> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
> Illegal Request: 0 Predictive Failure Analysis: 0
> c2t0d0           Soft Errors: 0 Hard Errors: 5 Transport Errors: 0
> Vendor: TSSTcorp Product: CD-ROM  TS-L162C Revision: N204 Serial No:
> Size: 0.00GB <0 bytes>
> Media Error: 0 Device Not Ready: 5 No Device: 0 Recoverable: 0
> Illegal Request: 0 Predictive Failure Analysis: 0
> c3t0d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
> Vendor: HP       Product: LOGICAL VOLUME   Revision: 1.92 Serial No:
> Size: 293.62GB <293621850112 bytes>
> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
> Illegal Request: 0 Predictive Failure Analysis: 0
> c3t1d0           Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
> Vendor: HP       Product: LOGICAL VOLUME   Revision: 1.92 Serial No:
> Size: 146.80GB <146803752960 bytes>
> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
> Illegal Request: 0 Predictive Failure Analysis: 0
> 
> S.


From stephen at atalanta-systems.com  Wed Nov 28 03:44:44 2012
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Wed, 28 Nov 2012 08:44:44 +0000
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <AAD6EACE-5207-48B8-9CEC-DF0AFD40380A@gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
	<CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
	<CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
	<AAD6EACE-5207-48B8-9CEC-DF0AFD40380A@gmail.com>
Message-ID: <CAOq1yR4vRVn-my7_xB2Jm4E9-KaWs8Z7yOKUfjL4xKf0o30ffw@mail.gmail.com>

Hi Andzrej,


On 28 November 2012 08:25, Andrzej Szeszo <aszeszo at gmail.com> wrote:
> Hi Stephen
>
> Did you manage to get installed system booting fine with the updated driver then?

Yes.  Will document on the wiki.  Thanks for the lead.

S.

From aszeszo at gmail.com  Wed Nov 28 03:47:21 2012
From: aszeszo at gmail.com (Andrzej Szeszo)
Date: Wed, 28 Nov 2012 09:47:21 +0100
Subject: [OmniOS-discuss] DL385G1
In-Reply-To: <CAOq1yR4vRVn-my7_xB2Jm4E9-KaWs8Z7yOKUfjL4xKf0o30ffw@mail.gmail.com>
References: <CAOq1yR5wOKOa7Z4-3ZKT0D86n0KY47DhOLU=Y2OM=t7AE3XrYA@mail.gmail.com>
	<F80EB0BF-4540-4372-A9BF-7715BC9DF342@gmail.com>
	<CAOq1yR7yKRuqShc3+0hO72dy8PK2g0CeotQfUA+Wodw_4nYEVg@mail.gmail.com>
	<CAOq1yR5ic=z8URPOXi+ZTD6edvG4HHWPKYkMf7xM+qrM+gaAcA@mail.gmail.com>
	<CAOq1yR535791LwvvufVTv17gsKABwsNuYHO+YurvGXDhbPGrNQ@mail.gmail.com>
	<AAD6EACE-5207-48B8-9CEC-DF0AFD40380A@gmail.com>
	<CAOq1yR4vRVn-my7_xB2Jm4E9-KaWs8Z7yOKUfjL4xKf0o30ffw@mail.gmail.com>
Message-ID: <E9B25ED0-EC07-4FEF-A0E5-577026F9AEF8@gmail.com>

Cool, great stuff.

Andrzej

On 28 Nov 2012, at 09:44, Stephen Nelson-Smith <stephen at atalanta-systems.com> wrote:

> Hi Andzrej,
> 
> 
> On 28 November 2012 08:25, Andrzej Szeszo <aszeszo at gmail.com> wrote:
>> Hi Stephen
>> 
>> Did you manage to get installed system booting fine with the updated driver then?
> 
> Yes.  Will document on the wiki.  Thanks for the lead.
> 
> S.


From lorban at bitronix.be  Wed Nov 28 07:50:52 2012
From: lorban at bitronix.be (Ludovic Orban)
Date: Wed, 28 Nov 2012 13:50:52 +0100
Subject: [OmniOS-discuss] dhcp client and DNS
Message-ID: <CAN0RhAO28q=2zv8m=Nj_=PvXQbpqe3+HWPGAAztAzJ7jvObMhg@mail.gmail.com>

Hi,

I've configured my ethernet interface with dhcp the following way:

ipadm create-addr -T dhcp rge0/v4

and that works fine except for two things:

1) DNS names resolving wasn't working. I've had to manually copy
/etc/nsswitch.dns to /etc/nsswitch.conf and manually create a
/etc/dhcp/eventhook script (much like described there:
https://blogs.oracle.com/darren/entry/dhcp_eventhook) to make DNS name
resolution working. Is that expected or is there a simpler way to
accomplish the same thing that I may have overlooked?

2) I want to "publish" my server's name to the DNS via the DHCP server. I
couldn't find a way to do it using ipadm so I reverted to using the old
Solaris 8 way, meaning I created an empty /etc/dhcp.rge0 file and a
/etc/hostname.rge0 file containing this single line: "inet
myWonderfulHostname". This all works fine except that once again I wonder
if there is a way to do the same with ipadm or some other newstyle tool.
While everything works fine, it looks like this setup confuses ipadm a bit
as it now sees two rge0 interfaces:

# ipadm show-addr
ADDROBJ           TYPE     STATE        ADDR
lo0/v4            static   ok           127.0.0.1/8
rge0/?            dhcp     ok           192.168.2.130/24
lo0/v6            static   ok           ::1/128
rge0/v4           dhcp     disabled     ?
#

I just wonder if there is a cleaner way to setup dhcp or if this is a
current limitation. In the latter case, is that a known problem being
worked on?


Thanks for your help,
Ludovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20121128/e30d5b43/attachment.html>

