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

2015-04-20 Thread 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

2015-04-20 Thread Dan McDonald

 On Apr 20, 2015, at 4:38 PM, Volker A. Brandt v...@bb-c.de 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

2015-04-20 Thread Eric Sproul
On Mon, Apr 20, 2015 at 4:38 PM, Volker A. Brandt v...@bb-c.de 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

2015-04-20 Thread 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

2015-04-20 Thread 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

2015-04-20 Thread Dan McDonald

 On Apr 20, 2015, at 1:11 PM, Volker A. Brandt v...@bb-c.de 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