Re: [OmniOS-discuss] Error attempting to switch to OpenSSH on r151014 or r151018

[Dan McDonald]

> On Jun 13, 2016, at 3:37 PM, Volker A. Brandt  wrote:
> 
> Aaaah, good clue!  I have a local copy of the 151016 repo. After a
> "pkgrepo refresh" on the repo server and a "pkg refresh --full" on
> the 151016 client, everything is well again, and "pkg search" works
> just fine.  Thanks Dan!

The trick (and I forget this more than I should) is to pkgrepo refresh after 
any pushes of new packages.  We just had a big push last week.

Glad this helps.  Now I'm going back to see how I broke zoneadmd in io-lx.  :-/

Dan

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

Re: [OmniOS-discuss] Error attempting to switch to OpenSSH on r151014 or r151018

[Dan McDonald]

> On Jun 13, 2016, at 2:49 PM, Dan McDonald  wrote:
> 
> I think our IPS repos need a batch of "pkgrepo refresh" runs.  I'm without 
> power at the moment, but I will make sure it gets done  once I access OmniTI 
> again.

I've got power:

r151018(~)[0]% pkg search /etc/ftpd
INDEX  ACTION VALUEPACKAGE
path   diretc/ftpd pkg:/SUNWcs@0.5.11-0.151018
r151018(~)[0]% pkg search /etc/ftpd/
r151018(~)[1]% pkg search /etc/ftpd/ftpusers 
INDEX  ACTION VALUE PACKAGE
path   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151018
r151018(~)[0]% 


Note that searching for a directory ending with / won't hit.

Dan

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

Re: [OmniOS-discuss] Error attempting to switch to OpenSSH on r151014 or r151018

[Dan McDonald]

I think our IPS repos need a batch of "pkgrepo refresh" runs.  I'm without 
power at the moment, but I will make sure it gets done  once I access OmniTI 
again.

Dan

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

On Jun 13, 2016, at 2:34 PM, Volker A. Brandt  wrote:

>>> On Mon, Jun 13, 2016 at 1:23 PM, Volker A. Brandt  wrote:
>>> BTW my 151016 system has the file, and SUNWcs is properly installed,
>>> but "pkg search /etc/ftpd" or "pkg search /etc/ftpd/ftpusers" do not
>>> show any output, even after a "pkg rebuild-index".  Strange.
>> 
>> Paths are relative because packages are relocatable, so I usually
>> search for a basename if it's relatively unambiguous.  `pkg search
>> ftpusers` should work, and return both a file and a softlink.  Note
>> that "basename" is a virtual attribute that doesn't actually appear in
>> the pkg manifest, but is synthesized by the client, based on the last
>> element of the path value.
>> 
>> This is on my 014 install:
>> 
>> $ pkg search ftpusers
>> INDEX  ACTION VALUE PACKAGE
>> basename   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014
>> basename   link   etc/ftpusers  pkg:/SUNWcs@0.5.11-0.151014
>> 
>> Using the full set of search fields also works, though I've never
>> understood why I need the '*' at the beginning of the path value:
>> 
>> $ pkg search 'file:path:*etc/ftpd/ftpusers'
>> INDEX  ACTION VALUE PACKAGE
>> path   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014
> 
> $ uname -a
> SunOS nfs 5.11 omnios-33c53a8 i86pc i386 i86pc
> 
> $ pkg version
> 1456488756
> 
> $ pkg search etc/ftpd/ftpusers
> Exit 1
> 
> $ pkg search /etc/ftpd/ftpusers
> Exit 1
> 
> $ pkg search 'file:path:*etc/ftpd/ftpusers'
> Exit 1
> 
> $  pkg list -v SUNWcs
> FMRI 
> IFO
> pkg://omnios/SUNWcs@0.5.11-0.151016:20160204T173743Z 
> i--
> 
> $ pkg contents SUNWcs|grep ftpd
> etc/ftpd
> etc/ftpd/ftpusers
> 
> $ pkg search /etc/default/ftp
> INDEX  ACTION VALUE   PACKAGE
> path   file   etc/default/ftp pkg:/network/ftp@0.5.11-0.151016
> 
> 
> Beats me.  I'll try this again after I have updated to 151018 in a 
> few days.
> 
> 
> 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] Error attempting to switch to OpenSSH on r151014 or r151018

[Volker A. Brandt]

> On Mon, Jun 13, 2016 at 1:23 PM, Volker A. Brandt  wrote:
> > BTW my 151016 system has the file, and SUNWcs is properly installed,
> > but "pkg search /etc/ftpd" or "pkg search /etc/ftpd/ftpusers" do not
> > show any output, even after a "pkg rebuild-index".  Strange.
>
> Paths are relative because packages are relocatable, so I usually
> search for a basename if it's relatively unambiguous.  `pkg search
> ftpusers` should work, and return both a file and a softlink.  Note
> that "basename" is a virtual attribute that doesn't actually appear in
> the pkg manifest, but is synthesized by the client, based on the last
> element of the path value.
>
> This is on my 014 install:
>
> $ pkg search ftpusers
> INDEX  ACTION VALUE PACKAGE
> basename   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014
> basename   link   etc/ftpusers  pkg:/SUNWcs@0.5.11-0.151014
>
> Using the full set of search fields also works, though I've never
> understood why I need the '*' at the beginning of the path value:
>
> $ pkg search 'file:path:*etc/ftpd/ftpusers'
> INDEX  ACTION VALUE PACKAGE
> path   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014

$ uname -a
SunOS nfs 5.11 omnios-33c53a8 i86pc i386 i86pc

$ pkg version
1456488756

$ pkg search etc/ftpd/ftpusers
Exit 1

$ pkg search /etc/ftpd/ftpusers
Exit 1

$ pkg search 'file:path:*etc/ftpd/ftpusers'
Exit 1

$  pkg list -v SUNWcs
FMRI IFO
pkg://omnios/SUNWcs@0.5.11-0.151016:20160204T173743Z i--

$ pkg contents SUNWcs|grep ftpd
etc/ftpd
etc/ftpd/ftpusers

$ pkg search /etc/default/ftp
INDEX  ACTION VALUE   PACKAGE
path   file   etc/default/ftp pkg:/network/ftp@0.5.11-0.151016


Beats me.  I'll try this again after I have updated to 151018 in a 
few days.


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] Error attempting to switch to OpenSSH on r151014 or r151018

[Eric Sproul]

On Mon, Jun 13, 2016 at 1:23 PM, Volker A. Brandt  wrote:
> BTW my 151016 system has the file, and SUNWcs is properly installed,
> but "pkg search /etc/ftpd" or "pkg search /etc/ftpd/ftpusers" do not
> show any output, even after a "pkg rebuild-index".  Strange.

Paths are relative because packages are relocatable, so I usually
search for a basename if it's relatively unambiguous.  `pkg search
ftpusers` should work, and return both a file and a softlink.  Note
that "basename" is a virtual attribute that doesn't actually appear in
the pkg manifest, but is synthesized by the client, based on the last
element of the path value.

This is on my 014 install:

$ pkg search ftpusers
INDEX  ACTION VALUE PACKAGE
basename   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014
basename   link   etc/ftpusers  pkg:/SUNWcs@0.5.11-0.151014

Using the full set of search fields also works, though I've never
understood why I need the '*' at the beginning of the path value:

$ pkg search 'file:path:*etc/ftpd/ftpusers'
INDEX  ACTION VALUE PACKAGE
path   file   etc/ftpd/ftpusers pkg:/SUNWcs@0.5.11-0.151014

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

Re: [OmniOS-discuss] Error attempting to switch to OpenSSH on r151014 or r151018

[Eric Sproul]

On Mon, Jun 13, 2016 at 11:46 AM, Volker A. Brandt  wrote:
> are hardcoded.  To avoid the problem here, the attempt to write to
> /etc/ftpd/ftpusers should only be made if the file actually exists.

But /etc/ftpd/ftpusers is provided by pkg:/SUNWcs, so if it doesn't
exist, the system is broken.  There is no expected case where this
file is missing.

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

Re: [OmniOS-discuss] Error attempting to switch to OpenSSH on r151014 or r151018

[Volker A. Brandt]

> > "leaving this here" so that others may find and benefit, and perhaps
> > the pkg rule will be cleaned up for OmniOS, now that ftpd isn't
> > there...
>
> It's currently a documented interface in pkg(5).  And I quote from the man 
> page:
>
>User Actions
>The user action defines a UNIX user as defined in /etc/passwd,
>/etc/shadow, /etc/group, and /etc/ftpd/ftpusers files. Entries are
>added to the appropriate files for users defined with this user action.
>
>The user action is intended to define a user for a daemon or other
>software to use. Do not use the user action to define administrative or
>interactive accounts.
>
> And weirder still, in spite of removing any default FTP server, the
> /etc/ftpd directory is part of the basic packages:

I think the OPs problem was that the file ftpusers had vanished.
In Solaris 11.x, both the file /etc/ftpd/ftpusers and the symlink
pointing to it (/etc/ftpusers) are packaged in system/core-os.

The underlying issue is that in the IPS source file

  /usr/lib/python2.6/vendor-packages/pkg/actions/user/.py

thíngs like

def install(self, pkgplan, orig, retry=False):
"""client-side method that adds the user...
   update any attrs that changed from orig
   unless the on-disk stuff was changed"""
[...]
pw.writefile()
gr.writefile()
ftp.writefile()
except EnvironmentError, e:
if e.errno != errno.ENOENT:
raise
# If we're in the postinstall phase and the files
# *still* aren't there, bail gracefully.
if retry:
txt = _("User cannot be installed without user "
"database files present.")
raise apx.ActionExecutionError(self, error=e,
details=txt, fmri=pkgplan.destination_fmri)

are hardcoded.  To avoid the problem here, the attempt to write to
/etc/ftpd/ftpusers should only be made if the file actually exists.


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] Error attempting to switch to OpenSSH on r151014 or r151018

[Dan McDonald]

> On Jun 12, 2016, at 7:01 PM, Rick Sayre  wrote:
> 
> "leaving this here" so that others may find and benefit, and perhaps 
> the pkg rule will be cleaned up for OmniOS, now that ftpd isn't 
> there... 

It's currently a documented interface in pkg(5).  And I quote from the man page:

   User Actions
   The user action defines a UNIX user as defined in /etc/passwd,
   /etc/shadow, /etc/group, and /etc/ftpd/ftpusers files. Entries are
   added to the appropriate files for users defined with this user action.

   The user action is intended to define a user for a daemon or other
   software to use. Do not use the user action to define administrative or
   interactive accounts.

And weirder still, in spite of removing any default FTP server, the /etc/ftpd 
directory is part of the basic packages:

bloody(~)[0]% pkg search /etc/ftpd
INDEX  ACTION VALUEPACKAGE
path   diretc/ftpd pkg:/SUNWcs@0.5.11-0.151019
bloody(~)[0]% 

I'm not sure what action uninstalled /etc/ftpd on your system, but that action 
is broken.  If it's a package in the "omnios" publisher, it's a bug for me to 
fix.  I doubt that's the case, however:

bloody(~)[0]% find ws/omnios-build/build -type f | xargs grep -l ftpd | grep -v 
build.log
bloody(~)[1]% 

I'm sorry about your pain.  The /etc/ftpd directory is a system-specified one, 
and it shouldn't be erased.

Dan

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