Re: [OmniOS-discuss] Bug ?

[Aurélien Larcher]

On 03/07/2017 16:41, Jim Klimov wrote:
> On July 1, 2017 1:02:30 AM GMT+02:00, "Aurélien Larcher" 
>  wrote:
>> I guess one should remind the little elves of the magical forest that
>> they need to take over the maintenance, they were quite busy with
>> Midsummer apparently.
>>
>> Otherwise, basically Guenther's advice is the way to go:
>> - for illumos specific issues: https://www.illumos.org/issues,
>> - for software package bugs we could look at it in OpenIndiana and
>> someone could backport the fix to OmniOS afterwards (when
>> infrastructure is fixed).
>>
>> I hoped that we could have a virtuous relationship with OpenIndiana
>> Hipster acting as a "bloody" and OmniOS continuing as a stable subset,
>> similarly to the current scheme (also benefiting from the current
>> Hipster CI setup to avoid losing momentum).
>> There is apparently no interest following the discussion which was
>> initiated right after the announcement, this is a bit disappointing.
>>
>> I hope that people will join forces to consolidate the landscape of
>> community-supported illumos distros.
>> At some point one needs to stop talking theory and tragedy, there are
>> pragmatic solutions to implement: there are infrastructures in place
>> in both OI and OmniOS-land, there are overall directions and goals in
>> both (rolling dev vs stable), there is a solid release engineering
>> practice in OmniOS, it does not seem like we swim in complete
>> abstraction.
>> Contributing software packages can be easy, the difficulty seems to
>> get people to figure out that maintaining even one package is a
>> meaningful contribution.
>>
>> (I maintain a bunch of packages for OpenIndiana and I do not work in
>> IT)
>>
>> Kind regards,
>>
>> À Jeudi 29 juin 2017, Davide Poletto a écrit :
>>> The more I think *how fast* that's (supposedly) happening the more I
>> feel
>>> shocked.
>>>
>>> On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients
>> Amstafs
>>> ::.."  wrote:
>>>
>>> Hi All,
>>>
>>> With pain in my heart, i fear OmniOs has started it's slow descent to
>> death
>>> :-(
>>>
>>>
>>>
>>> -Oorspronkelijk bericht-
>>> Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com]
>> Namens
>>> Paul B. Henson
>>> Verzonden: donderdag 29 juni 2017 22:13
>>> Aan: 'Guenther Alka' ;
>> omnios-discuss@lists.omniti.com
>>> Onderwerp: Re: [OmniOS-discuss] Bug ?
>>>
>>>> From: Guenther Alka
>>>> Sent: Thursday, June 29, 2017 12:33 AM
>>>>
>>>> There are no signs from OmniTi to add any fixes.
>>> An OmniTI person posted an intention to back port security fixes to
>> r151022
>>> for one year, although I'm not sure whether that was under the
>> auspices of
>>> OmniTI employment or just on his personal time. So far though, there
>> have
>>> been no new commits in the r151022 repo since Dan's last one on
>> 5/10..
>>>
>>> ___
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss@lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>> ...:: House of Ancients ::...
>>> American Staffordshire Terriers
>>>
>>> +31-628-161-350
>>> +31-614-198-389
>>> Het Perk 48
>>> 4903 RB
>>> Oosterhout
>>> Netherlands
>>> www.houseofancients.nl
>>> ___
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss@lists.omniti.com
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>
>> -- 
>> Thanks for sailing Jolla :)
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> Among technological differences between OI and OO, a notable benefit is LX 
> zones. It was often stated that OI community has not enough resources to 
> deviate from upstream illumos-gate, since maintaining a fork beyond a 
> branding patch or so is indeed complicated.
I guess it is more a matter of priority: we had the userland migration
ongoing and updating/integrating quite many components in the process
was very time consuming.
Last time we discussed LX the conclusion was that we need one person
dedicated to the task, and otherwise it is

Re: [OmniOS-discuss] Bug ?

[Dan McDonald]

> On Jul 3, 2017, at 10:41 AM, Jim Klimov  wrote:
> 
> 
> Among technological differences between OI and OO, a notable benefit is LX 
> zones. It was often stated that OI community has not enough resources to 
> deviate from upstream illumos-gate, since maintaining a fork beyond a 
> branding patch or so is indeed complicated.
> 
> I got wondering if it is possible to take omnios-gate and build just the 
> LX-related bits for the sake of adding the LX brand support as a few packages 
> installable to "vanilla" illumos-gate os/net? In the binary end, it does add 
> just some modules, tools and scripts, right? At least, if this works, it 
> might help until LX is upstreamed...

The LX port data (lists of commits from illumos-joyent I did and did not take), 
including the semi-automatic scripting I have for merging is all tarred up here:

https://omnios.omniti.com/wiki.php/Maintainers

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Jim Klimov]

On July 1, 2017 1:02:30 AM GMT+02:00, "Aurélien Larcher" 
 wrote:
>I guess one should remind the little elves of the magical forest that
>they need to take over the maintenance, they were quite busy with
>Midsummer apparently.
>
>Otherwise, basically Guenther's advice is the way to go:
>- for illumos specific issues: https://www.illumos.org/issues,
>- for software package bugs we could look at it in OpenIndiana and
>someone could backport the fix to OmniOS afterwards (when
>infrastructure is fixed).
>
>I hoped that we could have a virtuous relationship with OpenIndiana
>Hipster acting as a "bloody" and OmniOS continuing as a stable subset,
>similarly to the current scheme (also benefiting from the current
>Hipster CI setup to avoid losing momentum).
>There is apparently no interest following the discussion which was
>initiated right after the announcement, this is a bit disappointing.
>
>I hope that people will join forces to consolidate the landscape of
>community-supported illumos distros.
>At some point one needs to stop talking theory and tragedy, there are
>pragmatic solutions to implement: there are infrastructures in place
>in both OI and OmniOS-land, there are overall directions and goals in
>both (rolling dev vs stable), there is a solid release engineering
>practice in OmniOS, it does not seem like we swim in complete
>abstraction.
>Contributing software packages can be easy, the difficulty seems to
>get people to figure out that maintaining even one package is a
>meaningful contribution.
>
>(I maintain a bunch of packages for OpenIndiana and I do not work in
>IT)
>
>Kind regards,
>
>À Jeudi 29 juin 2017, Davide Poletto a écrit :
>> The more I think *how fast* that's (supposedly) happening the more I
>feel
>> shocked.
>>
>> On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients
>Amstafs
>> ::.."  wrote:
>>
>> Hi All,
>>
>> With pain in my heart, i fear OmniOs has started it's slow descent to
>death
>> :-(
>>
>>
>>
>> -Oorspronkelijk bericht-
>> Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com]
>Namens
>> Paul B. Henson
>> Verzonden: donderdag 29 juni 2017 22:13
>> Aan: 'Guenther Alka' ;
>omnios-discuss@lists.omniti.com
>> Onderwerp: Re: [OmniOS-discuss] Bug ?
>>
>> > From: Guenther Alka
>> > Sent: Thursday, June 29, 2017 12:33 AM
>> >
>> > There are no signs from OmniTi to add any fixes.
>>
>> An OmniTI person posted an intention to back port security fixes to
>r151022
>> for one year, although I'm not sure whether that was under the
>auspices of
>> OmniTI employment or just on his personal time. So far though, there
>have
>> been no new commits in the r151022 repo since Dan's last one on
>5/10..
>>
>>
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> ...:: House of Ancients ::...
>> American Staffordshire Terriers
>>
>> +31-628-161-350
>> +31-614-198-389
>> Het Perk 48
>> 4903 RB
>> Oosterhout
>> Netherlands
>> www.houseofancients.nl
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>
>-- 
>Thanks for sailing Jolla :)
>___
>OmniOS-discuss mailing list
>OmniOS-discuss@lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Among technological differences between OI and OO, a notable benefit is LX 
zones. It was often stated that OI community has not enough resources to 
deviate from upstream illumos-gate, since maintaining a fork beyond a branding 
patch or so is indeed complicated.

I got wondering if it is possible to take omnios-gate and build just the 
LX-related bits for the sake of adding the LX brand support as a few packages 
installable to "vanilla" illumos-gate os/net? In the binary end, it does add 
just some modules, tools and scripts, right? At least, if this works, it might 
help until LX is upstreamed...

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Andy Fiddaman]

On Sun, 2 Jul 2017, Tobias Oetiker wrote:

; not to join forces seem to be a pitty ... how about hosting that fork on
; https://github.com/omniosorg and starting to accept PRs there

At the moment the fork is very much driven by our requirements and not
considering a wider community. We're ignoring fixes that don't directly
affect us and pulling others that would historically only have made it
into bloody.

I do think we need to set up a fork on github.com/omniosorg but this one
probably isn't it. I'm on the gitter chat but the last thing you said on
there was "I have also on purpose NOT forked the omnios repo into the omnios
org thing yet". I'll take the conversation over there.

Andy

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Tobias Oetiker]

- On Jul 2, 2017, at 12:09 PM, Andy Fiddaman omn...@citrus-it.net wrote:

> On Thu, 29 Jun 2017, Guenther Alka wrote:
> 
> ; Unless there are news regarding OmniOS my stance is
> ;
> ; - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the
> ; most stable and feature rich free Illumos general use server distribution 
> with
> ; the addition LX zones. As there is no repo and development outside OmniTi it
> ; is freezed. There are no signs from OmniTi to add any fixes. As packages are
> ; signed it does not work outside OmniTi. As OmniOS 151023 is identical 
> without
> ; signed packages a community based repo based on it with possible fixes as
> ; 151022ce (community edition) is a suggestion (but sadly I am not an OS
> ; developer).
> 
> Momentum does appear to be lacking unfortunately. Here at Citrus we have
> forked the OmniOS repositories and are continuing to maintain them for
> internal use while we consider options.
> 
> We have kept omnios-build packages up-to-date where there are security
> fixes (two Bind updates, 7-zip CVE patch, OpenSSL [IIRC]) and backported a
> handful of illumos changes that are relevant to us. We can keep going like
> this for a good while and I still hope that a community OmniOS will get
> going (we've offered to contribute engineering resource as have others)
> and we can make the switch.
> 
> Since we use LX zones to an extent, SmartOS is the other route we are
> evaluating at the moment.
> 


not to join forces seem to be a pitty ... how about hosting that fork on
https://github.com/omniosorg and starting to accept PRs there

at least from what I can see there is a total lack of communication from omniti
regarding how they envision that transition of omnios to community 
maintainership

so I guess we have to take the initiative.

I have had a look at smartos, for kvm and lx it would be great but it seems 
that serving smb, nfs and iscsi
is not a focus on joyents side (but maybe I have just not looked correctly).

there is a gitter chat associated with the github omniosorg repo
https://gitter.im/omniosorg/Lobby



cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Andy Fiddaman]

On Thu, 29 Jun 2017, Guenther Alka wrote:

; Unless there are news regarding OmniOS my stance is
;
; - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the
; most stable and feature rich free Illumos general use server distribution with
; the addition LX zones. As there is no repo and development outside OmniTi it
; is freezed. There are no signs from OmniTi to add any fixes. As packages are
; signed it does not work outside OmniTi. As OmniOS 151023 is identical without
; signed packages a community based repo based on it with possible fixes as
; 151022ce (community edition) is a suggestion (but sadly I am not an OS
; developer).

Momentum does appear to be lacking unfortunately. Here at Citrus we have
forked the OmniOS repositories and are continuing to maintain them for
internal use while we consider options.

We have kept omnios-build packages up-to-date where there are security
fixes (two Bind updates, 7-zip CVE patch, OpenSSL [IIRC]) and backported a
handful of illumos changes that are relevant to us. We can keep going like
this for a good while and I still hope that a community OmniOS will get
going (we've offered to contribute engineering resource as have others)
and we can make the switch.

Since we use LX zones to an extent, SmartOS is the other route we are
evaluating at the moment.

Andy

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Günther Alka]

Why should one as there remain enough free or nonfree Solaris based 
options that I see as a mostly superiour option for ZFS storage.


Or would you switch (as a Linux user) to BSD or Solaris if RedHat would 
close the door when there are many other Linux options but without 
commercial support available.


If commercial support was your reason for OmniOS, Nexenta and Solaris 
remain an option. If OpenSource is ok, use OI or SmartOS or one of the 
other and hope or help that we/you/they find a way to continue the idea 
of a minimal stable or LTS distribution based on Illumos.Commercial 
support with SLA is not really needed for me and many. We want NetApp 
alike features without the costs.


I second Aurélian coming from the OpenIndiana community with the idea to 
look at OI with its stronger and already working community like a OmniOS 
bloody to create a stable subset/freeze named OmniOS upon.


Gea
@napp-it.org

Am 01.07.2017 um 01:36 schrieb Mini Trader:

Is it going to be FreeBSD or Linux?

On Thu, Jun 29, 2017 at 3:16 AM Oliver Weinmann 
<mailto:oliver.weinm...@telespazio-vega.de>> wrote:


Ohh that is bad news.

I have a productions system that somehow fails to join AD and I
don’t know what is causing this. We had a similar issue on our 
nexenta system and they provided us a patch that solved it.


Idmap:

additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information
(Client not found in Kerberos database)

adutils: ldap_lookup_init failed

*Oliver Weinmann*
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de
<mailto:oliver.weinm...@telespazio-vega.de>
http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht:
Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller

*From:* Paul B. Henson [mailto:hen...@acm.org
<mailto:hen...@acm.org>]
*Sent:* Donnerstag, 29. Juni 2017 08:51
*To:* Oliver Weinmann mailto:oliver.weinm...@telespazio-vega.de>>
*Cc:* omnios-discuss mailto:omnios-discuss@lists.omniti.com>>
    *Subject:* Re: [OmniOS-discuss] Bug ?

Unfortunately OmniTI no longer offers support contracts for
OmniOS. We actually have a contract that's still good through I
think November, but given their main support engineer is no longer
with the company and the OS appears to be in limbo at the moment
I'm not sure what good that does us ;).

If you think you've found a bug, your best bet at the moment is to
just report it to this list, possibly to the upstream illumos
developer list if you can detail it reasonably technically, and
perhaps open an issue on the illumos issue tracker.


On Jun 28, 2017, at 11:29 PM, Oliver Weinmann
mailto:oliver.weinm...@telespazio-vega.de>> wrote:

Hi,

What if I would like to report a possible bug? Do I need a
valid support contract for this?

Best Regards,

Oliver




*Oliver Weinmann*
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de
<mailto:oliver.weinm...@telespazio-vega.de>
http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register
court/Registergericht: Darmstadt, HRB 89231; Managing
Director/Geschäftsführer: Sigmar Keller

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
<mailto:OmniOS-discuss@lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
<mailto:OmniOS-discuss@lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


--

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Mini Trader]

Is it going to be FreeBSD or Linux?

On Thu, Jun 29, 2017 at 3:16 AM Oliver Weinmann <
oliver.weinm...@telespazio-vega.de> wrote:

> Ohh that is bad news.
>
>
>
> I have a productions system that somehow fails to join AD and I don’t know
> what is causing this. We had a similar issue on our  nexenta system and
> they provided us a patch that solved it.
>
>
>
> Idmap:
>
>
>
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (Client not found in
> Kerberos database)
>
> adutils: ldap_lookup_init failed
>
>
>
>
>
>
>
>
>
> *Oliver Weinmann*
> Senior Unix VMWare, Storage Engineer
>
> Telespazio VEGA Deutschland GmbH
> Europaplatz 5 - 64293 Darmstadt - Germany
> Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
> oliver.weinm...@telespazio-vega.de
> http://www.telespazio-vega.de
>
> Registered office/Sitz: Darmstadt, Register court/Registergericht:
> Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
>
> *From:* Paul B. Henson [mailto:hen...@acm.org]
> *Sent:* Donnerstag, 29. Juni 2017 08:51
> *To:* Oliver Weinmann 
> *Cc:* omnios-discuss 
> *Subject:* Re: [OmniOS-discuss] Bug ?
>
>
>
> Unfortunately OmniTI no longer offers support contracts for OmniOS. We
> actually have a contract that's still good through I think November, but
> given their main support engineer is no longer with the company and the OS
> appears to be in limbo at the moment I'm not sure what good that does us ;).
>
>
>
> If you think you've found a bug, your best bet at the moment is to just
> report it to this list, possibly to the upstream illumos developer list if
> you can detail it reasonably technically, and perhaps open an issue on the
> illumos issue tracker.
>
>
> On Jun 28, 2017, at 11:29 PM, Oliver Weinmann <
> oliver.weinm...@telespazio-vega.de> wrote:
>
> Hi,
>
>
>
> What if I would like to report a possible bug? Do I need a valid support
> contract for this?
>
>
>
> Best Regards,
>
> Oliver
>
>
>
>
> 
>
> *Oliver Weinmann*
> Senior Unix VMWare, Storage Engineer
>
> Telespazio VEGA Deutschland GmbH
> Europaplatz 5 - 64293 Darmstadt - Germany
> Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
> oliver.weinm...@telespazio-vega.de
> http://www.telespazio-vega.de
>
> Registered office/Sitz: Darmstadt, Register court/Registergericht:
> Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Aurélien Larcher]

I guess one should remind the little elves of the magical forest that
they need to take over the maintenance, they were quite busy with
Midsummer apparently.

Otherwise, basically Guenther's advice is the way to go:
- for illumos specific issues: https://www.illumos.org/issues,
- for software package bugs we could look at it in OpenIndiana and
someone could backport the fix to OmniOS afterwards (when
infrastructure is fixed).

I hoped that we could have a virtuous relationship with OpenIndiana
Hipster acting as a "bloody" and OmniOS continuing as a stable subset,
similarly to the current scheme (also benefiting from the current
Hipster CI setup to avoid losing momentum).
There is apparently no interest following the discussion which was
initiated right after the announcement, this is a bit disappointing.

I hope that people will join forces to consolidate the landscape of
community-supported illumos distros.
At some point one needs to stop talking theory and tragedy, there are
pragmatic solutions to implement: there are infrastructures in place
in both OI and OmniOS-land, there are overall directions and goals in
both (rolling dev vs stable), there is a solid release engineering
practice in OmniOS, it does not seem like we swim in complete
abstraction.
Contributing software packages can be easy, the difficulty seems to
get people to figure out that maintaining even one package is a
meaningful contribution.

(I maintain a bunch of packages for OpenIndiana and I do not work in IT)

Kind regards,

À Jeudi 29 juin 2017, Davide Poletto a écrit :
> The more I think *how fast* that's (supposedly) happening the more I feel
> shocked.
>
> On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients Amstafs
> ::.."  wrote:
>
> Hi All,
>
> With pain in my heart, i fear OmniOs has started it's slow descent to death
> :-(
>
>
>
> -Oorspronkelijk bericht-
> Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens
> Paul B. Henson
> Verzonden: donderdag 29 juni 2017 22:13
> Aan: 'Guenther Alka' ; omnios-discuss@lists.omniti.com
> Onderwerp: Re: [OmniOS-discuss] Bug ?
>
> > From: Guenther Alka
> > Sent: Thursday, June 29, 2017 12:33 AM
> >
> > There are no signs from OmniTi to add any fixes.
>
> An OmniTI person posted an intention to back port security fixes to r151022
> for one year, although I'm not sure whether that was under the auspices of
> OmniTI employment or just on his personal time. So far though, there have
> been no new commits in the r151022 repo since Dan's last one on 5/10..
>
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> ...:: House of Ancients ::...
> American Staffordshire Terriers
>
> +31-628-161-350
> +31-614-198-389
> Het Perk 48
> 4903 RB
> Oosterhout
> Netherlands
> www.houseofancients.nl
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

-- 
Thanks for sailing Jolla :)
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Davide Poletto]

The more I think *how fast* that's (supposedly) happening the more I feel
shocked.

On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients Amstafs
::.."  wrote:

Hi All,

With pain in my heart, i fear OmniOs has started it's slow descent to death
:-(



-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens
Paul B. Henson
Verzonden: donderdag 29 juni 2017 22:13
Aan: 'Guenther Alka' ; omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] Bug ?

> From: Guenther Alka
> Sent: Thursday, June 29, 2017 12:33 AM
>
> There are no signs from OmniTi to add any fixes.

An OmniTI person posted an intention to back port security fixes to r151022
for one year, although I'm not sure whether that was under the auspices of
OmniTI employment or just on his personal time. So far though, there have
been no new commits in the r151022 repo since Dan's last one on 5/10..


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Floris van Essen ..:: House of Ancients Amstafs ::..]

Hi All,

With pain in my heart, i fear OmniOs has started it's slow descent to death :-(



-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
Paul B. Henson
Verzonden: donderdag 29 juni 2017 22:13
Aan: 'Guenther Alka' ; omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] Bug ?

> From: Guenther Alka
> Sent: Thursday, June 29, 2017 12:33 AM
>
> There are no signs from OmniTi to add any fixes.

An OmniTI person posted an intention to back port security fixes to r151022 for 
one year, although I'm not sure whether that was under the auspices of OmniTI 
employment or just on his personal time. So far though, there have been no new 
commits in the r151022 repo since Dan's last one on 5/10..


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Paul B. Henson]

> From: Guenther Alka
> Sent: Thursday, June 29, 2017 12:33 AM
>
> There are no signs from OmniTi to add any fixes.

An OmniTI person posted an intention to back port security fixes to r151022 for 
one year, although I'm not sure whether that was under the auspices of OmniTI 
employment or just on his personal time. So far though, there have been no new 
commits in the r151022 repo since Dan's last one on 5/10..


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Paul B. Henson]

> From: Oliver Weinmann
> Sent: Thursday, June 29, 2017 12:14 AM
> 
> Ohh that is bad news.

Yes, it was quite disappointing :(, I really liked OmniOS.

> I have a productions system that somehow fails to join AD and I don’t know
> what is causing this. We had a similar issue on our  nexenta system and they
> provided us a patch that solved it.

How recently was that? There are nexenta people on this list, but more so on 
the illumos developer list, you might be able to get more details on 
specifically what that patch involved.


We currently use samba for CIFS under OmniOS as we need CIFS to hit AD and 
NFSv4 to use mit kerberos and currently the in kernel CIFS server won't do 
that; but in past testing we were able to connect the kernel CIFS server to AD 
without issue.


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Guenther Alka]

Unless there are news regarding OmniOS my stance is

- OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is 
the most stable and feature rich free Illumos general use server 
distribution with the addition LX zones. As there is no repo and 
development outside OmniTi it is freezed. There are no signs from OmniTi 
to add any fixes. As packages are signed it does not work outside 
OmniTi. As OmniOS 151023 is identical without signed packages a 
community based repo based on it with possible fixes as 151022ce 
(community edition) is a suggestion (but sadly I am not an OS developer).


Without LX and a former OmniOS alike support option available you can 
move to OpenIndiana as a 1:1 replacement.  OpenIndiana (current is 
2017.04) is more or less pure Illumos + an optional GUI + a lot of 
services in the repo. OpenIndiana is the idea to continue OpenSolaris. 
The OpenIndiana textedition is nearly identical to OmniOS beside LX. 
There is also a GUI option with Mate. If you avoid the bunch of extra 
services, media tools and office tools its a very stable option, just 
like OmniOS is/was. As there is no long term stable with backporting 
fixes you can use a snapshot like the 2017.04 and update single packages 
on OpenIndiana when needed. A pkg update gives you the whole newest 
Illumos similar to OmniOS bloody. Like OmniOS OpenIndiana offers a new 
snapshot + iso every 6 months. If there are bugs fixed in Illumos you 
get them on OI.


- You can report bugs regarding the distribution to the OpenIndiana 
list. Bugs that are related to core Illumos functionalities (OS, ZFS, 
drivers, core services like iSCSI, NFS, SMB) should be reported to the 
Illumos list optionally as an issue at https://www.illumos.org/issues 
(was the same with OmniOS). They get fixed there like it was with OmniOS.


setup of the different OI distributions
http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf


Gea
@napp-it.org



Am 29.06.2017 um 08:50 schrieb Paul B. Henson:
Unfortunately OmniTI no longer offers support contracts for OmniOS. We 
actually have a contract that's still good through I think November, 
but given their main support engineer is no longer with the company 
and the OS appears to be in limbo at the moment I'm not sure what good 
that does us ;).


If you think you've found a bug, your best bet at the moment is to 
just report it to this list, possibly to the upstream illumos 
developer list if you can detail it reasonably technically, and 
perhaps open an issue on the illumos issue tracker.


On Jun 28, 2017, at 11:29 PM, Oliver Weinmann 
> wrote:



Hi,

What if I would like to report a possible bug? Do I need a valid 
support contract for this?


Best Regards,

Oliver



*Oliver Weinmann*
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de 


http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht: 
Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com 
http://lists.omniti.com/mailman/listinfo/omnios-discuss



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.o


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Oliver Weinmann]

Ohh that is bad news.

I have a productions system that somehow fails to join AD and I don’t know what 
is causing this. We had a similar issue on our  nexenta system and they 
provided us a patch that solved it.

Idmap:

additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
failure.  Minor code may provide more information (Client not found in Kerberos 
database)
adutils: ldap_lookup_init failed






[cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1.png]

Oliver Weinmann
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de<mailto:oliver.weinm...@telespazio-vega.de>
http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, 
HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
From: Paul B. Henson [mailto:hen...@acm.org]
Sent: Donnerstag, 29. Juni 2017 08:51
To: Oliver Weinmann 
Cc: omnios-discuss 
Subject: Re: [OmniOS-discuss] Bug ?

Unfortunately OmniTI no longer offers support contracts for OmniOS. We actually 
have a contract that's still good through I think November, but given their 
main support engineer is no longer with the company and the OS appears to be in 
limbo at the moment I'm not sure what good that does us ;).

If you think you've found a bug, your best bet at the moment is to just report 
it to this list, possibly to the upstream illumos developer list if you can 
detail it reasonably technically, and perhaps open an issue on the illumos 
issue tracker.

On Jun 28, 2017, at 11:29 PM, Oliver Weinmann 
mailto:oliver.weinm...@telespazio-vega.de>> 
wrote:
Hi,

What if I would like to report a possible bug? Do I need a valid support 
contract for this?

Best Regards,
Oliver





Oliver Weinmann
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de<mailto:oliver.weinm...@telespazio-vega.de>
http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, 
HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com<mailto:OmniOS-discuss@lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Paul B. Henson]

Unfortunately OmniTI no longer offers support contracts for OmniOS. We actually 
have a contract that's still good through I think November, but given their 
main support engineer is no longer with the company and the OS appears to be in 
limbo at the moment I'm not sure what good that does us ;).

If you think you've found a bug, your best bet at the moment is to just report 
it to this list, possibly to the upstream illumos developer list if you can 
detail it reasonably technically, and perhaps open an issue on the illumos 
issue tracker. 

> On Jun 28, 2017, at 11:29 PM, Oliver Weinmann 
>  wrote:
> 
> Hi,
>  
> What if I would like to report a possible bug? Do I need a valid support 
> contract for this?
>  
> Best Regards,
> Oliver
>  
> 
> 
> 
> Oliver Weinmann
> Senior Unix VMWare, Storage Engineer
> 
> Telespazio VEGA Deutschland GmbH
> Europaplatz 5 - 64293 Darmstadt - Germany 
> Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
> oliver.weinm...@telespazio-vega.de
> http://www.telespazio-vega.de
> 
> Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, 
> HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug ?

[Oliver Weinmann]

Hi,

What if I would like to report a possible bug? Do I need a valid support 
contract for this?

Best Regards,
Oliver



[cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1.png]

Oliver Weinmann
Senior Unix VMWare, Storage Engineer

Telespazio VEGA Deutschland GmbH
Europaplatz 5 - 64293 Darmstadt - Germany
Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
oliver.weinm...@telespazio-vega.de
http://www.telespazio-vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, 
HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug 6569 r151020

[Dan McDonald]

> On Apr 1, 2017, at 12:07 PM, John Barfield  wrote:
> 
> Thanks for that! 

Add "-a" to that git branch:

git branch -a --contains 

That way you don't have to check out every branch in your local repo.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug 6569 r151020

[John Barfield]

Thanks for that! 

John Barfield
Engineering and Stuff 
 
M: +1 (214) 425-0783  O: +1 (214) 506-8354 
john.barfi...@bissinc.com
 

4925 Greenville Ave, Ste 900
Dallas, TX 75206
 
For Support Requests:
http://support.bissinc.com  or supp...@bissinc.com
 
Follow us on Twitter for Network Status &  Updates! 
 
  

On 4/1/17, 10:48 AM, "Dale Ghent"  wrote:

This isn't make it in to 020. It will be in the 022, the next LTS. We plan 
to make an announcement on that soon regarding its availability.

BTW, if you're curious if a specific commit is present in a particular 
branch in git, you can clone the repo and make sure the branches you're 
interested in are activated, and run the command:

git branch --contains 

and it will tell you which branch(es) that commit is in.

/dale

> On Apr 1, 2017, at 10:25 AM, John Barfield  
wrote:
> 
> Good morning,
> 
> Simple question today...I couldnt find an itemized list of bugfixes that 
are rolled into the latest release version so I wanted to see if this:
> 
> https://www.illumos.org/issues/6569
> 
> Is in r151020 or if I need to wait for the next LTS release, or if I 
needed to backport it.
> 
> Thanks and have a great weekend!
> 
> John Barfield
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug 6569 r151020

[Dale Ghent]

This isn't make it in to 020. It will be in the 022, the next LTS. We plan to 
make an announcement on that soon regarding its availability.

BTW, if you're curious if a specific commit is present in a particular branch 
in git, you can clone the repo and make sure the branches you're interested in 
are activated, and run the command:

git branch --contains 

and it will tell you which branch(es) that commit is in.

/dale

> On Apr 1, 2017, at 10:25 AM, John Barfield  wrote:
> 
> Good morning,
> 
> Simple question today...I couldnt find an itemized list of bugfixes that are 
> rolled into the latest release version so I wanted to see if this:
> 
> https://www.illumos.org/issues/6569
> 
> Is in r151020 or if I need to wait for the next LTS release, or if I needed 
> to backport it.
> 
> Thanks and have a great weekend!
> 
> John Barfield
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



signature.asc
Description: Message signed with OpenPGP
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug 6569 r151020

[John Barfield]

Good morning,

Simple question today...I couldnt find an itemized list of bugfixes that are 
rolled into the latest release version so I wanted to see if this:

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

Is in r151020 or if I need to wait for the next LTS release, or if I needed to 
backport it.

Thanks and have a great weekend!

John Barfield
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [Bug] Installer crashes on disk selection

[Dan McDonald]

This is a known issue with the current installer.  We're fixing this by 
replacing the installer for the next OmniOS release.

Please track bloody for the upcoming installer change.  If you can, boot off 
dhcp and use the Kayak PXE installer, which will form the basis of the new ISO 
one.

Dan

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

> On Feb 18, 2017, at 5:53 PM, lukas  wrote:
> 
> Hello,
> I stumbled upon an Bug in the OmniOS Installer where it crashes on the
> "Disks" Screen of the Installer. It happens at least in 
> "OmniOS_Text_r151020.iso"
> and "OmniOS_Text_bloody_20170117.iso" when used together with an 
> Paravirtualized
> Disk Driver inside an VM.
> 
> How to Reproduce
> 
> 
> On an Debian Stretch host, Run an Qemu VM with the "virtio" Disk Interface:
> 
> kvm -k de -smp 2 -drive file=OmniOS.img,if=virtio,format=raw -m 512M -monitor 
> stdio -net nic,model=e1000 -net user -cdrom OmniOS_Text_r151020.iso -vnc :0
> 
> The same also happens with Xen.
> 
> 
> /system/volatile/install_log
> 
> 
> 2017-02-18 22:38:25,313   InstallationLogger INFO    START    
> 
> PROGRESS REPORT: progress percent:0 Preparing for Installation
> PROGRESS REPORT: progress percent:100 TargetDiscovery completed.
> 2017-02-18 22:38:26,312   InstallationLogger INFO   -> [DataObjectCache] 
> ()
>-> [persistent] (DataObjectCacheChild: persistent)
>-> [sysconfig] 
> ()
>-> [discovered] ( 0x7b480690>)
>-> [disk] (Disk: ctd=c2d0; volid=None; 
> devpath=/xpvd/xdf@0; devid=None; wwn=None; prop:dev_size=15.99gb; 
> is_cdrom=False; label=VTOC; whole_disk=False; write_cache=False; active ctd 
> aliases=c2d0)
>-> [logical] (Logical: noswap=True; nodump=True)
>-> [Engine-DOC-Root-Node] ( object at 0x7b480cd0>)
>-> [TargetDiscovery] 
> ( 0x7b5ed710>)
>-> [desired] ( 0x7b480910>)
>-> [logical] (Logical: noswap=False; nodump=False)
>-> [rpool] (Zpool: name=rpool; action=create; 
> is_root=True; vdev_list=[None])
>-> [vdev] (Vdev: name=vdev; 
> redundancy=none)
>-> [omnios] (BE: name=omnios; 
> mountpoint=/a)
>-> [volatile] (DataObjectCacheChild: volatile)
>-> [apply_sysconfig_dict] 
> ( 0x7b5d1790>)
>-> [transfer-ti-files] 
> ( 0x7b4de450>)
> 2017-02-18 22:38:26,313   InstallationLogger INFO   Install Data:
> Install Completed - False
> Log Location - /system/volatile/install_log
> Log Final - /var/log/install/install_log
> No Install Mode - False
> 2017-02-18 22:38:26,313   InstallationLogger ERROR  Install failed
> 
> Traceback (most recent call last):
>  File 
> "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/__init__.py",
>  line 421, in main
>screen = screen.show()
>  File "/usr/lib/python2.7/vendor-packages/terminalui/base_screen.py", line 
> 149, in show
>self._show()
>  File 
> "/usr/lib/python2.7/vendor-packages/solaris_install/text_install/disk_selection.py",
>  line 399, in _show
>self.disk_win.activate_object(self.selected_disk_index)
>  File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 
> 338, in activate_object
>self.activate_object_force(index=index, loop=loop, force_to_top=jump)
>  File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 
> 352, in activate_object_force
>jump=force_to_top)
>  File "/usr/lib/python2.7/vendor-packages/terminalui/inner_window.py", line 
> 318, in activate_object
>raise IndexError(err_msg)
> IndexError: Index (0) out of range (0-0)
> 2017-02-18 22:38:26,315   InstallationLogger INFO    END
>  
> 
> 
> format
> ==
> 
> Searching for disks...done
> 
> 
> AVAILABLE DISK SELECTIONS:
>   0. c2d0 
>  /xpvd/xdf@0
> Specify disk (enter its number):
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] [Bug] Installer crashes on disk selection

[lukas]

Hello,
I stumbled upon an Bug in the OmniOS Installer where it crashes on the
"Disks" Screen of the Installer. It happens at least in 
"OmniOS_Text_r151020.iso"
and "OmniOS_Text_bloody_20170117.iso" when used together with an Paravirtualized
Disk Driver inside an VM.

How to Reproduce


On an Debian Stretch host, Run an Qemu VM with the "virtio" Disk Interface:

kvm -k de -smp 2 -drive file=OmniOS.img,if=virtio,format=raw -m 512M -monitor 
stdio -net nic,model=e1000 -net user -cdrom OmniOS_Text_r151020.iso -vnc :0

The same also happens with Xen.


/system/volatile/install_log


2017-02-18 22:38:25,313   InstallationLogger INFO    START  
  
PROGRESS REPORT: progress percent:0 Preparing for Installation
PROGRESS REPORT: progress percent:100 TargetDiscovery completed.
2017-02-18 22:38:26,312   InstallationLogger INFO   -> [DataObjectCache] 
()
-> [persistent] (DataObjectCacheChild: persistent)
-> [sysconfig] 
()
-> [discovered] ()
-> [disk] (Disk: ctd=c2d0; volid=None; 
devpath=/xpvd/xdf@0; devid=None; wwn=None; prop:dev_size=15.99gb; 
is_cdrom=False; label=VTOC; whole_disk=False; write_cache=False; active ctd 
aliases=c2d0)
-> [logical] (Logical: noswap=True; nodump=True)
-> [Engine-DOC-Root-Node] ()
-> [TargetDiscovery] 
()
-> [desired] ()
-> [logical] (Logical: noswap=False; nodump=False)
-> [rpool] (Zpool: name=rpool; action=create; 
is_root=True; vdev_list=[None])
-> [vdev] (Vdev: name=vdev; 
redundancy=none)
-> [omnios] (BE: name=omnios; 
mountpoint=/a)
-> [volatile] (DataObjectCacheChild: volatile)
-> [apply_sysconfig_dict] 
()
-> [transfer-ti-files] 
()
2017-02-18 22:38:26,313   InstallationLogger INFO   Install Data:
Install Completed - False
Log Location - /system/volatile/install_log
Log Final - /var/log/install/install_log
No Install Mode - False
2017-02-18 22:38:26,313   InstallationLogger ERROR  Install failed  
  
Traceback (most recent call last):
  File 
"/usr/lib/python2.7/vendor-packages/solaris_install/text_install/__init__.py", 
line 421, in main
screen = screen.show()
  File "/usr/lib/python2.7/vendor-packages/terminalui/base_screen.py", line 
149, in show
self._show()
  File 
"/usr/lib/python2.7/vendor-packages/solaris_install/text_install/disk_selection.py",
 line 399, in _show
self.disk_win.activate_object(self.selected_disk_index)
  File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 
338, in activate_object
self.activate_object_force(index=index, loop=loop, force_to_top=jump)
  File "/usr/lib/python2.7/vendor-packages/terminalui/scroll_window.py", line 
352, in activate_object_force
jump=force_to_top)
  File "/usr/lib/python2.7/vendor-packages/terminalui/inner_window.py", line 
318, in activate_object
raise IndexError(err_msg)
IndexError: Index (0) out of range (0-0)
2017-02-18 22:38:26,315   InstallationLogger INFO    END
 


format
==

Searching for disks...done


AVAILABLE DISK SELECTIONS:
   0. c2d0 
  /xpvd/xdf@0
Specify disk (enter its number):
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug #6842 - is it in Omni stable yet?

[Dale Ghent]

> On Aug 16, 2016, at 8:41 AM, Lawrence Giam  wrote:
> 
> Hi All,
> 
> I have been experiencing this bug quite a lot. Looking up and found that this 
> bug have been push up to illumos-gate and I would like to know if OmniOS have 
> got this implement in stable?
> 
> If yes, may I know which version and build?

Yes, this fix is in 151014 and newer.

/dale
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug #6842 - is it in Omni stable yet?

[Davide Poletto]

Hi!

It looks like it's there on OmniOS 151014 (current LTS):

https://github.com/omniti-labs/illumos-omnios/blob/r151014/usr/src/uts/common/fs/zfs/zap.c

since the April, 21st update Release.

See Release Notes here:
https://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 ...about "ZFS fixes
for Samba & SMB sharers (illumos 6841-6843)".

It is also present, AFAIK since beginning, on OmniOS 151018 (current
Stable):
https://github.com/omniti-labs/illumos-omnios/blob/r151018/usr/src/uts/common/fs/zfs/zap.c

As into OmniOS Master Branch:
https://github.com/omniti-labs/illumos-omnios/commits/master/usr/src/uts/common/fs/zfs/zap.c

Regards, Davide.

On Tue, Aug 16, 2016 at 2:41 PM, Lawrence Giam 
wrote:

> Hi All,
>
> I have been experiencing this bug quite a lot. Looking up and found that
> this bug have been push up to illumos-gate and I would like to know if
> OmniOS have got this implement in stable?
>
> If yes, may I know which version and build?
>
> Thanks & Regards.
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug #6842 - is it in Omni stable yet?

[Lawrence Giam]

Hi All,

I have been experiencing this bug quite a lot. Looking up and found that
this bug have been push up to illumos-gate and I would like to know if
OmniOS have got this implement in stable?

If yes, may I know which version and build?

Thanks & Regards.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Peter Tribble]

On Wed, Jun 10, 2015 at 7:12 PM, Michael Rasmussen  wrote:

> On Wed, 10 Jun 2015 17:04:20 +0100
> Peter Tribble  wrote:
>
> >
> > Delete that line in powertop.c and all should be well.
> >
>

FYI, I've looged illumos bug #6003

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


> Do I need to build the entire illumos-gate to recompile powertop?
>

No. It can often be awkward to build individual tools, but as this is
a too that started out life elsewhere it's pretty easy. You don't even
need to pull the whole of the gate.

svn co https://github.com/illumos/illumos-gate/trunk/usr/src/cmd/powertop
cd powertop/common
[edit powertop.c]
gcc -m64 -c *.c ../amd64/pt_amd64.c
gcc -m64 -o powertop *.o -ldtrace -lkstat -lcurses

> (I get the following as well:
> > powertop: failed to compile P-states (frequencies) program
> > powertop: failed to compile C-states (idle power) program
> > so I'm not sure it's actually functional.)
> >
> You need to run powertop either as root or using sudo.
>

That's not it. Run it without adequate privileges and it will explicitly
tell you so. Tracing this a little further (this isn't on an omnios box,
by the way, but powertop *should* be the same) and attempting to
run the dtrace it creates by hand, I get.

"/usr/lib/dtrace/scsi.d", line 46: translator member ic_cdb definition uses
incompatible types: "uint8_t *" = "user_desc_t"

At which point I gave up, because (a) I don't understand dtrace well
enough, and (b) the types used in the code look fine to me, and (c)
other than the fact that it fails to compile, whether this is actually the
compilation failure being reported by powertop is anyone's guess.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Michael Rasmussen]

On Wed, 10 Jun 2015 17:04:20 +0100
Peter Tribble  wrote:

> 
> Delete that line in powertop.c and all should be well.
> 
Do I need to build the entire illumos-gate to recompile powertop?

> (I get the following as well:
> powertop: failed to compile P-states (frequencies) program
> powertop: failed to compile C-states (idle power) program
> so I'm not sure it's actually functional.)
> 
You need to run powertop either as root or using sudo.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--
/usr/games/fortune -es says:
Q:  What do little WASPs want to be when they grow up?
A:  The very best person they can possibly be.


pgpb4awfaYBn4.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Peter Tribble]

On Tue, Jun 9, 2015 at 4:45 PM, Michael Rasmussen  wrote:

> Hi all,
>
> Anybody able to start powertop using some of the available options?
> root@nas:/root# powertop -d 1
> Segmentation Fault (core dumped)
>

Oh, that's bad.

Look at:


http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/powertop/common/powertop.c#81

which is:

char *optarg;

So, when getopt_long parses the arguments and pokes things back into
optarg, where's it going to end up? Not the right optarg, hence the SEGV
when strtod() is called on the local optarg.

Delete that line in powertop.c and all should be well.

(I get the following as well:
powertop: failed to compile P-states (frequencies) program
powertop: failed to compile C-states (idle power) program
so I'm not sure it's actually functional.)

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Michael Rasmussen]

On Wed, 10 Jun 2015 09:34:03 -0500 (CDT)
Bob Friesenhahn  wrote:

> 
> I have read that powertop uses DTrace probes under Illumos.  Does it link 
> against a dtrace library?  Has the interface changed?
> 
If it is linked dynamically to DTrace then you shouldn't see a
segmentation fault unless the source does not check for null-pointer
references. Statically linked to DTrace and you should not be able to
pass the linker stage.

> Another possibility is the internationalization changes (from scratch 
> re-write) in Illumos.  Check the locale settings.  Locale settings could 
> influence string to decimal conversion.
> 
This could be an explanation but I doubt it. My default locale is C and
I have run some test with LANG configured to en, en_US, en_UK but
without any change.

My best guess is a bug in the code so I will fetch the source and run
it through gdb.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--
/usr/games/fortune -es says:
Never keep up with the Joneses. Drag them down to your level.
-- Quentin Crisp


pgpOT7GzP42Lc.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Bob Friesenhahn]

On Tue, 9 Jun 2015, Zach Malone wrote:


This sounds like a libc or kernel change, but I can't imagine why it
would show up on both 012 and 014.  Maybe someone with a working build
environment can dig further?


I have read that powertop uses DTrace probes under Illumos.  Does it 
link against a dtrace library?  Has the interface changed?


Another possibility is the internationalization changes (from scratch 
re-write) in Illumos.  Check the locale settings.  Locale settings 
could influence string to decimal conversion.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug in powertop

[Zach Malone]

I gave this a go on 151012 (014 isn't available as an AMI yet, and I
can't get the 006 AMI to accept a ssh key pair on instance creation),
and saw the same thing.  powertop appears to segfault in
string_to_decimal / libc.so.1.

I then tried rebuilding powertop from the OmniTI illumos-gate build
scripts, but found that omnios-build:build/illumos/build.sh is a
little fussy for the uninitiated.

This sounds like a libc or kernel change, but I can't imagine why it
would show up on both 012 and 014.  Maybe someone with a working build
environment can dig further?
--Zach Malone

On Tue, Jun 9, 2015 at 9:45 AM, Michael Rasmussen  wrote:
> Hi all,
>
> Anybody able to start powertop using some of the available options?
> root@nas:/root# powertop -d 1
> Segmentation Fault (core dumped)
> root@nas:/root# powertop -t 10
> Segmentation Fault (core dumped)
> root@nas:/root# powertop -d 1 -v
> Segmentation Fault (core dumped)
> root@nas:/root# powertop -c 0
> Segmentation Fault (core dumped)
>
> The only way I am able to start powertop is using defaults.
>
> Omnios: OmniOS v11 r151014
>
> --
> Hilsen/Regards
> Michael Rasmussen
>
> Get my public GnuPG keys:
> michael  rasmussen  cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir  datanom  net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir  miras  org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --
> /usr/games/fortune -es says:
> He hated being thought of as one of those people that wore stupid
> ornamental armour. It was gilt by association.
> -- Terry Pratchett, "Night Watch"
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] bug in powertop

[Michael Rasmussen]

Hi all,

Anybody able to start powertop using some of the available options?
root@nas:/root# powertop -d 1  
Segmentation Fault (core dumped)
root@nas:/root# powertop -t 10
Segmentation Fault (core dumped)
root@nas:/root# powertop -d 1 -v
Segmentation Fault (core dumped)
root@nas:/root# powertop -c 0   
Segmentation Fault (core dumped)

The only way I am able to start powertop is using defaults.

Omnios: OmniOS v11 r151014

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--
/usr/games/fortune -es says:
He hated being thought of as one of those people that wore stupid
ornamental armour. It was gilt by association.
-- Terry Pratchett, "Night Watch"


pgp68VbMudzj9.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Volker A. Brandt]

> As I understand it (someone please correct me if I'm wrong), we
> cannot use Oracle's pkg-gate unmodified, as it has dependencies on
> closed bits in Solaris for certain features.  Those need to be
> stripped/modified for non-Solaris use, which is what OI has been
> maintaining in their fork, thanks mostly to the hard work of Andrzej
> Szeszo.  Anyone interested in helping refresh
> https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit
> both communities.

Thanks for the info Eric!  A quick glance at that URL shows that
people are working on it.  Last commit was March 9th by Alexander
Pyhalov.

I'll ping the OI guys as to what kind of effort is needed.  Don't
hold your breath though. :-)


Regards -- Volker
-- 

Volker A. Brandt   Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Volker A. Brandt]

> >> The OmniOS version of pkg(5) is a downstream of OpenIndiana's,
> >> which is in turn a downstream of Oracle's, but last synched in
> >> 2013 (because Oracle uses hg, and git from hg is annoying).
> >
> > Interesting, wasn't aware of that.  So is it really just a matter
> > of mercurial->git conversion, or has the OI/Omni version of pkg
> > diverged too much?
> >
> > if the former, maybe one of the many tools could be leveraged that
> > pull stuff out of hg repos and push it into git?
>
> I don't know.  I don't do the downstreaming from Oracle... OI does.

OK, I will post a query to the OI dev list when I have time.

> Just running pkg.depotd in the foreground.
>
>   /usr/lib/pkg.depotd -p 2112 -d blah
>
> Port 2112, with "blah" being a pkgrepo(1M) directory.

Neat trick for debugging, thanks.

[...]
> > ...but the pkg/server:my-pub instance listens on another port,
> > hence the 404 codes.
>
> I'd have to look deeper, and maybe enable more debugging output.

The 404 is expected.  That was just to show the "pkg/1427212657".

> > Going forward, what is the likelihood of OmniOS adopting a more
> > recent version of the Oracle IPS gate?  I don't really think I can
> > offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well
> > worth while if it fixes that bug.
>
> I have enough else pulling at me at the moment I can't look at this
> deeply right now.

Understood.  Same here.  Thanks for having a look!


Regards -- Volker
-- 

Volker A. Brandt   Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Eric Sproul]

On Mon, Apr 20, 2015 at 4:38 PM, Volker A. Brandt  wrote:
>> wonder if this bug was around a while, and that's why it's
>> "ms.omniti.com" instead of "omniti-ms", for example?
>
> Sounds likely.  I wouldn't know. :-)

I would know, as I was the one that chose it when I was at OmniTI.  :)

The various OmniTI "extra" publishers (those other than omnios) use
the pseudo-domain-name style, simply for the high degree of confidence
that it is globally unique.  I was unaware of the issue with dashes in
publisher names, but IIRC way back at the beginning (circa 2011) when
we started working on what would become OmniOS, I'm pretty sure there
was an "omni-os" publisher configured.  Perhaps the issue was
introduced in a later revision (one that's in the OI fork) but only
fixed after the last time OI synced their tree.

> Going forward, what is the likelihood of OmniOS adopting a more recent
> version of the Oracle IPS gate?  I don't really think I can offer much
> help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if
> it fixes that bug.

As I understand it (someone please correct me if I'm wrong), we cannot
use Oracle's pkg-gate unmodified, as it has dependencies on closed
bits in Solaris for certain features.  Those need to be
stripped/modified for non-Solaris use, which is what OI has been
maintaining in their fork, thanks mostly to the hard work of Andrzej
Szeszo.  Anyone interested in helping refresh
https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit
both communities.

Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Dan McDonald]

> On Apr 20, 2015, at 4:38 PM, Volker A. Brandt  wrote:
> 
> Hi Dan!
>> 
>> Dug through my mail, and I didn't see this note.  I may have lost
>> it, but gmail is usually good about not letting you get rid of
>> mails.  :(
> 
> Well, I sent it to @omniti.com.  My guess is you don't see any of
> my mails because they are filtered away.  But no matter, as long as
> the discuss list works, that's fine.

I may have deleted it while reading on my phone (which can happen more than I'd 
like).

>> The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which
>> is in turn a downstream of Oracle's, but last synched in 2013
>> (because Oracle uses hg, and git from hg is annoying).
> 
> Interesting, wasn't aware of that.  So is it really just a matter
> of mercurial->git conversion, or has the OI/Omni version of pkg
> diverged too much?
> 
> if the former, maybe one of the many tools could be leveraged that
> pull stuff out of hg repos and push it into git?

I don't know.  I don't do the downstreaming from Oracle... OI does.

> 
>> wonder if this bug was around a while, and that's why it's
>> "ms.omniti.com" instead of "omniti-ms", for example?
> 
> Sounds likely.  I wouldn't know. :-)

I mention that for the list's benefit, because that decision was made before I 
arrived at OmniTI.

>> ANYWAY, my toy server with an empty repo had this in its logs:
>> 
>> 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 ""
>> "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full;
>> pkg)"
> 
> Interesting.  Where does that log come from?  Do you have an Apache
> with redirect rules sitting in front of your repo?

Just running pkg.depotd in the foreground.

/usr/lib/pkg.depotd -p 2112 -d blah

Port 2112, with "blah" being a pkgrepo(1M) directory.

>  I did play around
> with redirects and rewrite rules, but wasn't really happy, so I decided
> to concentrate on one problem at a time.  My Apache logs show similar
> entries when I tell the IPS client to use port 80 (where an Apache is
> listening on the pkg server host):
> 
> 192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] "GET /my-repo/versions/0/
> HTTP/1.1" 404 220 "-" "pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full;
> pkg)"
> 
> ...but the pkg/server:my-pub instance listens on another port, hence
> the 404 codes.

I'd have to look deeper, and maybe enable more debugging output.

> Going forward, what is the likelihood of OmniOS adopting a more recent
> version of the Oracle IPS gate?  I don't really think I can offer much
> help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if
> it fixes that bug.

I have enough else pulling at me at the moment I can't look at this deeply 
right now.

Sorry,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Volker A. Brandt]

Hi Dan!


> > This is paraphrased from a mail that I had sent to Dan privately
> > on March 31st.  Unfortunately, the problem still persists in
> > 151014.
> 
> Dug through my mail, and I didn't see this note.  I may have lost
> it, but gmail is usually good about not letting you get rid of
> mails.  :(

Well, I sent it to @omniti.com.  My guess is you don't see any of
my mails because they are filtered away.  But no matter, as long as
the discuss list works, that's fine.
 
> I'm seeing a different variant of this error using a toy repo I set
> up.  It has to be an http repo using pkg.depotd.  If I use a
> file:/// URL, it appears to work.

Exactly.  Good to know that I am not imagining things.
 
> The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which
> is in turn a downstream of Oracle's, but last synched in 2013
> (because Oracle uses hg, and git from hg is annoying).

Interesting, wasn't aware of that.  So is it really just a matter
of mercurial->git conversion, or has the OI/Omni version of pkg
diverged too much?

if the former, maybe one of the many tools could be leveraged that
pull stuff out of hg repos and push it into git?

> The github
> URL is https://github.com/omniti-labs/pkg5/ if you wanna poke around
> in the source we use.  NOTE we have per-release branches starting
> with r151014, but the "default master" is called "omnios" because
> we're a downstream child of another downstream child.

Thanks for the pointer, but I guess it would take me ages to spot,
let alone fix the bug.
 
> I don't know of anyone who uses dashes in their publisher name.

Well, now you know. :-)  BTW IHAC who uses lots of dashes in lots
of publisher names under Solaris... just a matter of taste I guess.

> wonder if this bug was around a while, and that's why it's
> "ms.omniti.com" instead of "omniti-ms", for example?

Sounds likely.  I wouldn't know. :-)
 
> ANYWAY, my toy server with an empty repo had this in its logs:
> 
> 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 ""
> "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full;
> pkg)"

Interesting.  Where does that log come from?  Do you have an Apache
with redirect rules sitting in front of your repo?  I did play around
with redirects and rewrite rules, but wasn't really happy, so I decided
to concentrate on one problem at a time.  My Apache logs show similar
entries when I tell the IPS client to use port 80 (where an Apache is
listening on the pkg server host):

192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] "GET /my-repo/versions/0/
HTTP/1.1" 404 220 "-" "pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full;
pkg)"

...but the pkg/server:my-pub instance listens on another port, hence
the 404 codes.


Going forward, what is the likelihood of OmniOS adopting a more recent
version of the Oracle IPS gate?  I don't really think I can offer much
help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if
it fixes that bug.


Regards -- Volker
-- 

Volker A. Brandt   Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Dan McDonald]

> On Apr 20, 2015, at 1:11 PM, Volker A. Brandt  wrote:
> 
> Hello all!
> 
> 
> This is paraphrased from a mail that I had sent to Dan privately on 
> March 31st.  Unfortunately, the problem still persists in 151014.

Dug through my mail, and I didn't see this note.  I may have lost it, but gmail 
is usually good about not letting you get rid of mails.  :(

> There seems to be a bug in the IPS version that comes with OmniOS.  If 
> there is a dash in the publisher name and the repo is accessed via http,
> it breaks:
> 
>  omnitest# pkg set-publisher -g http://omnios-server:12345/ my-pub
>  pkg set-publisher: Could not refresh the catalog for my-pub
> 
>  http protocol error: code: 400 reason: Bad Request
>  URL: 'http://omnios-server:12345/my-pub/catalog/1/catalog.attrs'
> 
> It does not matter if the client is OmniOS or Solaris 11.2, it always
> breaks.

I'm seeing a different variant of this error using a toy repo I set up.  It has 
to be an http repo using pkg.depotd.  If I use a file:/// URL, it appears to 
work.

> The Solaris 11.2 SRU8 /usr/bin/pkg has CLIENT_API_VERSION = 79, whereas
> the OmniOS /usr/bin/pkg is at CLIENT_API_VERSION = 75.  So my guess is
> that the bug was fixed upstream somewhere between the pkg version 
> shipped with OmniOS 151014 and the one shipped S11.2 SRU 8.

The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn 
a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and 
git from hg is annoying).  The github URL is 
https://github.com/omniti-labs/pkg5/ if you wanna poke around in the source we 
use.  NOTE we have per-release branches starting with r151014, but the "default 
master" is called "omnios" because we're a downstream child of another 
downstream child.

> Has anyone seen this problem before?  Or does anyone have an OmniOS
> system successfully serving IPS packages with a dash in the publisher
> name?  Any and all info gratefully accepted!  It is entirely possible
> that I am doing something wrong, but I don't really know where to look.

I don't know of anyone who uses dashes in their publisher name.  I wonder if 
this bug was around a while, and that's why it's "ms.omniti.com" instead of 
"omniti-ms", for example?

ANYWAY, my toy server with an empty repo had this in its logs:

127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 "" 
"pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg)"
127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /publisher/0/ HTTP/1.1" 200 57 "" 
"pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg)"

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash

[Volker A. Brandt]

Hello all!


This is paraphrased from a mail that I had sent to Dan privately on 
March 31st.  Unfortunately, the problem still persists in 151014.

There seems to be a bug in the IPS version that comes with OmniOS.  If 
there is a dash in the publisher name and the repo is accessed via http,
it breaks:

  omnitest# pkg set-publisher -g http://omnios-server:12345/ my-pub
  pkg set-publisher: Could not refresh the catalog for my-pub
   
  http protocol error: code: 400 reason: Bad Request
  URL: 'http://omnios-server:12345/my-pub/catalog/1/catalog.attrs'

It does not matter if the client is OmniOS or Solaris 11.2, it always
breaks.

If I run that same command against a Solaris 11.2 server with an
identical repository, it works.  If I use the identical repo locally,
it works.   If I mount the repository via NFS from an OmniOS server,
it works.  All combinations work, except the one I want:  The repo
served from an OmniOS box via http. :-(

The SMF service itself runs fine, no maintenance mode, no error messages,
nothing.  It is only when I try to set the publisher on the client,
and the client wants to retrieve the catalog, I get the above error.

When I researched this bug before I found a reference to it somewhere,
saying that it is a bug in cherrypy, but I can't find that reference
again, now that I look for it.

The Solaris 11.2 SRU8 /usr/bin/pkg has CLIENT_API_VERSION = 79, whereas
the OmniOS /usr/bin/pkg is at CLIENT_API_VERSION = 75.  So my guess is
that the bug was fixed upstream somewhere between the pkg version 
shipped with OmniOS 151014 and the one shipped S11.2 SRU 8.

Has anyone seen this problem before?  Or does anyone have an OmniOS
system successfully serving IPS packages with a dash in the publisher
name?  Any and all info gratefully accepted!  It is entirely possible
that I am doing something wrong, but I don't really know where to look.


Thanks -- Volker
-- 

Volker A. Brandt   Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in omnios packaging

[Eric Sproul]

On Mon, Dec 8, 2014 at 10:24 AM, Eric Sproul  wrote:
> Haha... busted!  Thanks for the bug report.  For whatever reason,
> these compression tools all have very non-standard build procedures,
> and make all sorts of silly assumptions.  We'll get it fixed.

The fix was to make the symlink target relative instead of absolute.

pkg://ms.omniti.com/omniti/compress/pbzip2@1.1.8,5.11-0.151006:20141208T180943Z
is the updated package.

Thanks again for pointing that out!
Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in omnios packaging

[Eric Sproul]

On Mon, Dec 8, 2014 at 8:29 AM, Jim Klimov  wrote:
> Hi all,
>
>
> Found a small issue in some of the omnios (ms.omniti.com) packages: they
> include symlinks that point to the build-host's absolute paths, i.e.:
>
>
> # find /opt/omni -ls | grep tmp
>  122950 lrwxrwxrwx   1 root root   66 Dec  8 13:39
> /opt/omni/bin/pbzcat ->
> /tmp/build_esproul/omniti_compress_pbzip2_pkg//opt/omni/bin/pbzip2
>  122960 lrwxrwxrwx   1 root root   66 Dec  8 13:39
> /opt/omni/bin/pbunzip2 ->
> /tmp/build_esproul/omniti_compress_pbzip2_pkg//opt/omni/bin/pbzip2
>  123020 lrwxrwxrwx   1 root root   68 Dec  8 13:39
> /opt/omni/bin/amd64/unpigz ->
> /tmp/build_esproul/omniti_compress_pigz_pkg//opt/omni/bin/amd64/pigz

Haha... busted!  Thanks for the bug report.  For whatever reason,
these compression tools all have very non-standard build procedures,
and make all sorts of silly assumptions.  We'll get it fixed.

Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug in omnios packaging

[Jim Klimov]

 Hi all,




 Found a small issue in some of the omnios (ms.omniti.com) packages: they 
include symlinks that point to the build-host's absolute paths, i.e.:




 # find /opt/omni -ls | grep tmp
  122950 lrwxrwxrwx   1 root root   66 Dec  8 13:39 
/opt/omni/bin/pbzcat -> 
/tmp/build_esproul/omniti_compress_pbzip2_pkg//opt/omni/bin/pbzip2
  122960 lrwxrwxrwx   1 root root   66 Dec  8 13:39 
/opt/omni/bin/pbunzip2 -> 
/tmp/build_esproul/omniti_compress_pbzip2_pkg//opt/omni/bin/pbzip2
  123020 lrwxrwxrwx   1 root root   68 Dec  8 13:39 
/opt/omni/bin/amd64/unpigz -> 
/tmp/build_esproul/omniti_compress_pigz_pkg//opt/omni/bin/amd64/pigz




 Cheers,

 //Jim
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug: OmniOS r151008j terminates iSCSI initiator too early in shutdown

[Chris Siebenmann]

I wrote:
|  As far as I can tell from simply looking at things right now, even
| an orderly shutdown on an OmniOS system will not avoid this.

 I should clarify that: 'on a normal, stock setup OmniOS system'.
You can of course add SMF jobs to import and export ZFS pools and then
shim them into the dependency order, but an out of the box OmniOS system
does not do this right.

(I'm not convinced it's ever possible to do it right without the
administrator having to explicitly configure things, but maybe there's a
way to make all of the magic work if the right SMF jobs were present by
default.)

- cks
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug: OmniOS r151008j terminates iSCSI initiator too early in shutdown

[Chris Siebenmann]

| On 2014-03-07 21:49, Chris Siebenmann wrote:
| >   In at least OmniOS r151008j, the iSCSI initiator and thus any iSCSI
| > disks it has established are shut down relatively early during a shutdown
| > or reboot. In specific they are terminated before halt et al runs
| > '/sbin/bootadm -ea update_all' (in halt.c's do_archives_update()).
| > Under some circumstances this will cause system shutdown to hang.
[...]
| >   Presumably either bootadm should be run earlier or iSCSI initiator
| > shutdown should happen later or both.
| 
| I guess you can control the order of shutdown procedures with
| SMF dependencies. In particular, it might be helpful to ensure
| that your system completely exports the remote-hosted pools
| before disabling iSCSI (and possibly networking, etc.).

 Unfortunately exporting pools on shutdown is an ugly and potentially
fragile workaround with a number of side effects (and one that was not
necessary on Solaris 10).

 As far as I can tell from simply looking at things right now, even
an orderly shutdown on an OmniOS system will not avoid this. I don't see
anything that inactivates pools[*] or even unmounts ZFS filesystems even
in an orderly shutdown. And SMF shutdown procedures are deliberately
bypassed if you just run 'reboot' (it's in the manpage if you read all
the way to the end and ignore the fact that it doesn't talk about SMF).

- cks
[*: partly because there is no user-level way to do this as far as I
know. Explicitly exporting a pool is a different thing.]
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug: OmniOS r151008j terminates iSCSI initiator too early in shutdown

[Jim Klimov]

On 2014-03-07 21:49, Chris Siebenmann wrote:

  In at least OmniOS r151008j, the iSCSI initiator and thus any iSCSI
disks it has established are shut down relatively early during a shutdown
or reboot. In specific they are terminated before halt et al runs
'/sbin/bootadm -ea update_all' (in halt.c's do_archives_update()).
Under some circumstances this will cause system shutdown to hang.

  Suppose that you have ZFS pools that are hosted on iSCSI disks and
those pools are set to the default 'failmode=wait'. When the iSCSI disks
go away due to initiator shutdown, those pools enter a state where any
IO to them will stall. Unfortunately bootadm does such IO (or at least
does something that stalls in ZFS-land) and as such will itself stall,
which stalls the shutdown process.

  Presumably either bootadm should be run earlier or iSCSI initiator
shutdown should happen later or both.


I guess you can control the order of shutdown procedures with
SMF dependencies. In particular, it might be helpful to ensure
that your system completely exports the remote-hosted pools
before disabling iSCSI (and possibly networking, etc.).

I hope that my write-up on the OI wiki would be relevant here:
http://wiki.openindiana.org/oi/Advanced+-+ZFS+Pools+as+SMF+services+and+iSCSI+loopback+mounts

Likewise, any of your services which need data from this pool
and can be wrapped into SMF (like VM's, zones, etc.) can also be
sure to stop properly before you export the pool and stop iSCSI.

http://wiki.openindiana.org/display/oi/Zones+as+SMF+services

I do mean to brush up those articles and code samples into a
more proper form (a package or something), but in the meanwhile
the articles can do with some manual work on the user's side ;)

HTH,
//Jim


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug: OmniOS r151008j terminates iSCSI initiator too early in shutdown

[Chris Siebenmann]

 In at least OmniOS r151008j, the iSCSI initiator and thus any iSCSI
disks it has established are shut down relatively early during a shutdown
or reboot. In specific they are terminated before halt et al runs
'/sbin/bootadm -ea update_all' (in halt.c's do_archives_update()).
Under some circumstances this will cause system shutdown to hang.

 Suppose that you have ZFS pools that are hosted on iSCSI disks and
those pools are set to the default 'failmode=wait'. When the iSCSI disks
go away due to initiator shutdown, those pools enter a state where any
IO to them will stall. Unfortunately bootadm does such IO (or at least
does something that stalls in ZFS-land) and as such will itself stall,
which stalls the shutdown process.

 Presumably either bootadm should be run earlier or iSCSI initiator
shutdown should happen later or both.

- cks
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug report: java in r151008 missing libjli.so

[Olaf Marzocchi]

Hello,
“java” doesn’t work in r151008 (libjli.so not found) unless the dev package is 
installed.
Check:

$ java  
ld.so.1: java: fatal: libjli.so: open failed: No such file or directory
Killed
$ ldd /usr/bin/java
libthread.so.1 =>/lib/libthread.so.1
libjli.so => (file not found)
libdl.so.1 =>/lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
$ env
TERM=xterm-256color
SHELL=/bin/bash
CLICOLOR=1
LSCOLORS=gxfxcxdxbxegedabagacad
PATH=/usr/bin:/bin:/usr/local/bin:/usr/sbin:/opt/omni/bin/
SHLVL=1
_=/usr/bin/env
$ pkg search libjli.so
INDEX  ACTION VALUE   PACKAGE
basename   file   usr/java/lib/i386/jli/libjli.so 
pkg:/developer/java/jdk@0.5.11-0.151008
basename   file   usr/java/jre/lib/i386/jli/libjli.so 
pkg:/runtime/java@0.5.11-0.151008
$ pkg info java
  Name: runtime/java
   Summary: Open-source implementation of the seventh edition of the Java 
SE Platform
 State: Installed
 Publisher: omnios
   Version: 0.5.11 (jdk7u21-b30)
 Build Release: 5.11
Branch: 0.151008
Packaging Date: Wed Dec  4 20:10:13 2013
  Size: 105.29 MB
  FMRI: pkg://omnios/runtime/java@0.5.11,5.11-0.151008:20131204T201013Z
$ ldd -s `which java`
…
   find object=libjli.so; required by /usr/java/bin/java
search path=$ORIGIN/../lib/i386/jli:/usr/openwin/lib  (RUNPATH/RPATH from 
file /usr/java/bin/java)
trying path=/usr/java/bin/../lib/i386/jli/libjli.so
trying path=/usr/openwin/lib/libjli.so
search path=/lib:/usr/lib:/usr/local/lib  (configuration default - 
/var/ld/ld.config)
trying path=/lib/libjli.so
trying path=/usr/lib/libjli.so
trying path=/usr/local/lib/libjli.so
libjli.so => (file not found)
…

It is not found because the file is not in 
/usr/java/bin/../lib/i386/jli/libjli.so but in 
/usr/java/bin/../jre/lib/i386/jli/libjli.so (the difference is “/jre”).

After installing the dev package, everything is fine.
The standard package has been linked on the dev libraries.
Checked on a clean install.

I don’t know whether this also bring lower performances (I expect a dev lib to 
be slower, but I’m no expert).

Regards
Olaf
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug in 'zfs userspace -t ....'

[Mark Harrison]

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

Looks like it made it into 151008, and the fix hasn't yet.

On Tue, Jan 28, 2014 at 3:34 PM, Chris Siebenmann  wrote:
>  zfs userspace -t  is documented as taking 'posixuser' as a type,
> and this is traditional Solaris 10 behavior. In OmniOS r151008j, this
> gets:
> # zfs userspace -t posixuser -H -o used,name -s name -p rpool/ROOT
> invalid type 'posixuser' for -t option
>
> Inspection of /usr/sbin/zfs with 'strings' shows that somehow it has
> become 'posxiuser' (and testing shows that this works). This change
> doesn't appear to be in the current Illumos upstream and I can't see
> any changeset related to this in a casual browse.
>
> - cks
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Mark Harrison
Lead Site Reliability Engineer
OmniTI
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Bug in 'zfs userspace -t ....'

[Chris Siebenmann]

 zfs userspace -t  is documented as taking 'posixuser' as a type,
and this is traditional Solaris 10 behavior. In OmniOS r151008j, this
gets:
# zfs userspace -t posixuser -H -o used,name -s name -p rpool/ROOT
invalid type 'posixuser' for -t option

Inspection of /usr/sbin/zfs with 'strings' shows that somehow it has
become 'posxiuser' (and testing shows that this works). This change
doesn't appear to be in the current Illumos upstream and I can't see
any changeset related to this in a casual browse.

- cks
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug tracking

[Bill Rees]

Why, yes!  Thanks.

Bill


On Thu, Jul 18, 2013 at 7:32 AM, Dale Ghent  wrote:

> On Jul 17, 2013, at 6:27 PM, Bill Rees  wrote:
>
> > Is there an external interface to the bug tracking system?
>
> Are you looking for this?
>
> http://omnios.omniti.com/query.php
>
> /dale
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] bug tracking

[Dale Ghent]

On Jul 17, 2013, at 6:27 PM, Bill Rees  wrote:

> Is there an external interface to the bug tracking system?

Are you looking for this? 

http://omnios.omniti.com/query.php

/dale

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] bug tracking

[Bill Rees]

Is there an external interface to the bug tracking system?

Thanks,
Bill Rees
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss