[OmniOS-discuss] New in r151018 -- lastlog changes

[Dan McDonald]

There are two illumos bugs:  6057 & 6594.  The first was pushed upstream, but 
then backed out.  The second bug fixes one of the big reasons the first got 
backed out.  The problem is, there are always 3rd-party apps.

These changes affect the way lastlog, and pam_open_session are implemented.  
With OmniOS-built packages (ones from the "omnios" publisher), we've recompiled 
things to use the new lastlog.  It's just a recompilation.  The problem is, 
potentially lots of older software that {,mis-}uses pam_open_session(), and 
that older software will break if run stock on r151018.

I'm curious if adopters of r151018 are noticing anything weird about their 
software that uses pam_open_session().  In particular, look for surprise 
printings (or double-printings) of "Last login at" messages.

I'm asking because there's some resistance to allowing these to go upstream 
into illumos-gate, and I want to know how broken the world is from r151018 
users' POV, because it already has these fixes in place.

Thanks,
Dan

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

Re: [OmniOS-discuss] Similar tools like flowadm

[Richard Elling]

> On May 3, 2016, at 7:57 PM, Ergi Thanasko  wrote:
> 
> Hi Dan,
> Yes is it a zfs pool shared over NFS. Yup going through the rabbit whole, but 
> I can wait for a while I have patience. Any help is appreciated thank you 

The most direct approach is to use multiple IP addresses: one per pool. Then 
you have a destination 
address for the flowadm tuple. 
 — richard

> 
> Sent from my iPhone
> 
>> On May 3, 2016, at 7:10 PM, Dan McDonald  wrote:
>> 
>> 
>>> On May 3, 2016, at 7:54 PM, Ergi Thanasko  wrote:
>>> 
>>> Hi guys,
>>> Is there any tools like flowadm that can control   bandwidth usage on a per 
>>> pool basis? instead of host ip. Also flowadm will use both in/out summary 
>>> to  limit bandwidth. We are looking for something deeper that we can 
>>> seperate control on incoming or outgoing or traffic at a pool level .
>> 
>> flowadm only controls network abstractions.  When you say "pool", do you 
>> mean zfs pool?  If so, does that mean with NFS, or iSCSI, or SMB, or some 
>> other file-sharer TBD?!?  You're going down a rabbit hole you can't get back 
>> out of quickly.
>> 
>> Sorry,
>> Dan
>> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--

richard.ell...@richardelling.com
+1-760-896-4422



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

Re: [OmniOS-discuss] Similar tools like flowadm

[Ergi Thanasko]

Thank you Dan and Jim for confirming that. So you guys recommend ipfilter, this 
server is in lab environment my firewall is off, just do not need it. Do i need 
the firewall on for the ipfilter to work ?



> On May 4, 2016, at 5:47 AM, Dan McDonald  wrote:
> 
> 
>> On May 4, 2016, at 12:08 AM, Jim Klimov  wrote:
>> 
>> By context, the ipfilter IP address pools also match the question, better :-)
> 
> Good point.
> 
>> Alas, no idea OTOH if flowadm has integration with those, or if ipfilter has 
>> a bandwidth facility.
> 
> ipfilter does not have a bandwidth facility.
> 
> Dan
> 
> 

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

Re: [OmniOS-discuss] 151018 "entire" missing library/python-2/jsonrpclib-26?

[Volker A. Brandt]

Hi Dan!


> > I guess that's because library/python-2/jsonrpclib-26 is missing from
> > the "entire" incorporation, thus it's not version-locked into 151016.
> > 
> > Right? :-)
> 
> Correct, and probably not a huge deal, because you shouldn't be jumping
> versions without REALLY jumping versions (i.e. uninstalling the
> not-yet-replaced ms.omniti.com packages).

Yes, that's what I usually do.  This time I did not really mean to
update, just did a dry run.

>  We take pull-requests in
> omnios-build.  :) 

OK :-)

> NOTE:  ms.omniti.com new builds of any package do not present this problem,
> as they are not build with the incorporate dependency. 

Ah, that's really good news indeed!  I see that you have made the
dependency on the "entire" incorporation optional, with a minimum
version of 151016.  Now I only need to wait until all my fav pkgs
are rebuilt. :-)


While we're on this topic, the repo itself is in need ot a bit of
maintenance.  Every operation still results in the old complaint
about the publisher (we have talked about this before):

  # pkg list -avf -g http://pkg.omniti.com/omniti-ms/ omniti/server/apache22
  Refreshing catalog 4/5 omniti-ms
  Unable to retrieve package data for publisher 'omniti-ms' from one
  of the following origin(s):

  http://pkg.omniti.com/omniti-ms/

  The catalog retrieved from one of the origin(s) listed above only
  contains package data for: ms.omniti.com.

  To resolve this issue, correct the origin information provided for
  publisher 'omniti-ms' using the pkg set-publisher subcommand, or re-add
  the publisher using the correct name and remove the 'omniti-ms'
  publisher.

  To re-add this publisher with the correct name, execute the following
  commands as a privileged user:

  pkg set-publisher -P -g http://pkg.omniti.com/omniti-ms/ ms.omniti.com
  pkg unset-publisher omniti-ms

  FMRI 
IFO
  pkg://ms.omniti.com/omniti/server/apache22@2.2.31-0.151016:20160504T141410Z  
---
  pkg://ms.omniti.com/omniti/server/apache22@2.2.31-0.151016:20151106T141513Z  
i--
  pkg://ms.omniti.com/omniti/server/apache22@2.2.31-0.151014:20150908T160723Z  
---
  [...]


Also, some packages simply cannot be retrieved:  

  # /usr/bin/pkgrecv -v -m latest -s http://pkg.omniti.com/omniti-ms/ -d 
/pkg/ms.omniti.com/ '*'
  Processing packages for publisher omniti-ms ...
  Retrieving catalog 1/1 omniti-ms 135.07 kB
  Unable to retrieve package data for publisher 'omniti-ms' from one
  of the following origin(s):

  [...]

  Retrieving and evaluating 981 package(s)...

  Retrieving packages ...
  Packages to add: 981
  Files to retrieve:  201950
  Estimated transfer size: 2.04 GB

  Packages to transfer:
  network/iftop@1.0.2,5.11-0.151006:20130816T191418Z
  network/logstash@1.1.12,5.11-0.151004:20130816T192505Z
  network/stunnel@4.53,5.11-0.151002:20120719T180653Z
  [...]
  service/network/tcpdump@4.3.0,5.11-0.151002:20130816T193841Z

  PROCESS ITEMSGET (MB)   SEND (MB)
  network/iftop   0/981  0/2092  0/6374
  pkgrecv: 'open' failed for transaction ID 
'1376680458_pkg%3A%2F%2Fms.omniti.com%2Fnetwork%2Fiftop%401.0.2%2C5.11-0.151006%3A20130816T191418Z':
 The specified FMRI, 
'pkg://ms.omniti.com/network/iftop@1.0.2,5.11-0.151006:20130816T191418Z', 
already exists or has been restricted.
  Exit 1

Does anyone care about network/iftop from 2013?  Maybe it can just 
be zapped?  There are some 3-4 more pkgs that break pkgrecv.


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