gmane.os.solaris.opensolaris.pkg.general

Re: Code review reminder: pkg/update fix and sysrepo config resiliency

Edward Pilatowicz — 2013-03-22T22:28:30

lgtm.
thanks for fixing this.
ed

Re: p5p package install with parent dependency within local zones

Edward Pilatowicz — 2013-03-22T21:31:28

your options are:

- detach the zone, do the update, and then re-attach the zone in the new
  post-u1 BE (this only works if you're upgrading to/past u1).

- extract the contenst of the p5p package and create a local http based
  repo and configure the gz to use that.

- temporarly configure the p5p in the ngz from the gz.  the trick here
  is the *from the gz* part.  ie, you'd do:

pkg -R /zonepath/root set-publisher -g /file_path.p5p <publisher>

  the reason this should work is because when pkg update recurses into
  the ngz it will attempt to lookup the p5p archive path relative to the
  gz root.

ed

Re: pkg-discuss Digest, Vol 67, Issue 14

Sajith C R — 2013-03-21T16:02:56

Hi Tim,
Thanks for the replay.
I found following two cases do not work
1. Copy the p5p file to global zone and local zone but their paths are
different on global zone and local zone. Set the publisher on global zone
and local zone with #pkg set-publisher -g <path> <publisher> command with
corresponding path.Say /tmp on global zone and / on local zone.
in this case package install fails with following error
----------------------------------------------
A 'sync-linked' operation failed for child 'zone:testzone' with an
unexpected
return value of 1 and the following error message:
pkg: 0/1 catalogs successfully updated:

Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
file protocol error: code: 22 reason: The path '/Mypkg.p5p' does not
contain a valid package repository.
Repository URL: 'file:///Mypkg.p5p'.

----------------------------------------------
2. if we try to set the publisher on global zone, with pkg set-publisher -p
option, then the SMF service /application/pkg/system-repository in global
zone will go to maintenance state and thus do not allow to set a publisher
in local zone.

But when I repeat the step #1 with my p5p package with same path say /tmp
on global and local zone (and with -g option to set-publisher), package
install works fine on both  global zone and local zone.

is this intentional?
The pkgrepo out for global and local zones are same as below
# pkgrepo -s /tmp/Mypkg.p5p list
PUBLISHER NAME                                          O VERSION
testpub  Mypkg
1.0.100.0,5.11:20130112T013032Z


On Wed, Mar 20, 2013 at 5:32 PM, <pkg-discuss-request< at >opensolaris.org>wrote:

Re: Code review reminder: pkg/update fix and sysrepo config resiliency

Tim Foster — 2013-03-20T22:57:44

Hi all,

Sorry for the follow up on this, there was some conversation about this 
service this morning (and the breakage in build 17 that this bug fixes)

On 03/20/13 11:07 AM, Erik Trauschke wrote:

in particular, how it should deal with users that have commented out the 
crontab entry the service creates.  I've a one-line change here that 
specifically looks for uncommented entries when deciding to add a new 
entry that I'd like to include with this putback:

---
diff --git a/src/svc/pkg5_include.sh b/src/svc/pkg5_include.sh
--- a/src/svc/pkg5_include.sh
+++ b/src/svc/pkg5_include.sh
< at >< at > -152,7 +152,7 < at >< at >
  $CRONTAB -l > $current_crontab
  EXIT=0
  # if the crontab doesn't already contain our command, add it
-$GREP -q " $CMD"$ $current_crontab
+$GREP -q "^[0-9, \*]+ $CMD"$ $current_crontab
  if [ $? -ne 0 ]; then
  $GREP -v " ${CMD}"$ $current_crontab > $new_crontab
  echo "$SCHEDULE $CMD" >> $new_crontab

---

the upshot is, if you've manually commented out the crontab entry, then 
by enabling the service, it will always add it back in.

Without this change, if you enable the service, then comment-out the 
crontab entry, and stop/start the service, the service will appear to be 
online without the cronjob ever actually firing, which seems like a 
worse user-experience to me.

I know this risks confusing the user ("Hey, I commented out that cron 
entry, how come it keeps coming back!?") but ultimately, I hope that 
some work elsewhere will help us from needing to deal with cron at all, 
so this will be a short-lived annoyance at worst.

cheers,
tim

Re: IPS project migrating to java.net

Danek Duvall — 2013-03-20T16:53:07

A friendly reminder: March 24 is the last day this list will be active, and
that the IPS source repository will be available.  Everyone who wants to
must switch over to the java.net versions, which you can get to via

    http://java.net/projects/ips

In order to shake out some of the remaining transition steps, I've locked
the gate, and request that further pushes go to the java.net gate.  I'll
continue syncing in the other direction for the next few days.

I've also put the list in "emergency moderation mode", which means that all
messages to the list will be moderated.  In addition, all posters will get
a reminder to switch over, no more than once a day.  All this annoyance is
in an effort to remind people to switch to the other list.  I'll allow all
(non-spam) messages through anyway, but there may be some delay.  Given the
low volume these days, I don't expect many people (including the list
moderators) should be especially inconvenienced by this.

I expect this will be my last note on this subject.

Holler if you notice any problems.

Thanks,
Danek

Re: Code review reminder: pkg/update fix and sysrepo config resiliency

Tim Foster — 2013-03-19T22:37:09

Thanks for taking a look!


Yep, I'll fix that.


Sure - I tried to address that in the comment at the top of 
add_cronjob().  In this case, $CMD is unique in that it contains the 
full SMF FMRI of the service we're looking to add/remove, eg.

"/usr/sbin/svcadm refresh svc:/application/pkg/mirror:default"

It specifically doesn't include the rest of the cron entry (namely the 
cron schedule) because that can change as the user modifies SMF properties.

For the consumers of this function, pkg/update and pkg/mirror, this is 
enough I think.  Yes, the pkg/update service would potentially clash if 
we had more than one instance of the service running, since the command 
it uses is:

"/usr/lib/update-manager/update-refresh.sh"

but that doesn't seem likely (and I hope we get to nuke pkg/update real 
soon now anyway - its use of root's crontab is disturbing..)


Thanks for looking at these webrevs, much appreciated!

cheers,
tim

Re: Code review reminder: pkg/update fix and sysrepo config resiliency

Erik Trauschke — 2013-03-19T22:07:56


On 03/19/13 01:51 PM, Tim Foster wrote:

lgtm


154: nit: /contains/contain/

you're testing only for the existence of ${CMD} in the whole crontab.
How likely is it that this test might find something the user put in 
there (or asked differently, how unique is ${CMD})?

Erik

Code review reminder: pkg/update fix and sysrepoconfig resiliency

Tim Foster — 2013-03-19T20:51:25

Hi there,

Just a quick reminder that I've got two small fixes out for code review 
at the moment, and was wondering if anyone had time to take a look?

The webrevs are:

https://cr.opensolaris.org/action/browse/pkg/timf/sysrepo-resilient-config/sysrepo-resilient-config-webrev/

https://cr.opensolaris.org/action/browse/pkg/timf/add-cronjob/add_cronjob-webrev

The original mails to pkg-discuss were:

Subject: Code review: making pkg.sysrepo more resilient in the face of 
inaccessible file repos
  (sent 02/26)

Subject: Code review: add_cronjob failing after unclean shutdown
  (sent 03/14)

cheers,
tim

Re: p5p package install with parent dependency within local zones

Tim Foster — 2013-03-19T20:03:32

hi there,

On 03/20/13 12:54 AM, Sajith C R wrote:

When you're doing the update, are you replacing the .p5p file with an 
updated version in both the global and non-global zone?  Otherwise, 
that's the sort of error I'd expect you to run into.

If that doesn't solve the problem, could you include more details as to 
the specific error you're seeing, along with the output for 'pkgrepo -s 
<p5p file> list'

cheers,
tim

p5p package install with parent dependency withinlocal zones

Sajith C R — 2013-03-19T11:54:41

Hi IPS team,
I am facing following issue with p5p archive package install inside local
zones on solaris 11.
I use p5p format package to install my package on solaris 11 and the
package contains following entries in the manifest to define parent
dependency.

depend type=parent fmri=feature/package/dependency/self
variant.opensolaris.zone=nonglobal

Prior to solaris 11 update, since the file based p5p publisher is not
propagated inside a zone automatically, I had to install the p5p package
inside local zones by copying the p5p file inside zone and then setting
publisher inside zone which was working fine for me.

with parent dependency mentioned, the package upgrades are not working with
my p5p format packages.
When publisher is set at global zone, IPS complain about version mismatch
with local zone.
If global zone is upgraded after detaching the local zone, later zone
attach fails because of package version mismatch.

I want to how to upgrade such packages on a pre-solaris 11 update1 setups?

With solaris 11u1 onwards, this issue is not there as both global zone and
local zones are updates together.

Thanks in advance.

Re: How to repair /etc/pam.conf

Alta Elstad — 2013-03-18T23:07:45

The information is also available under:

Fixing Package Problems > Restoring a File

http://docs.oracle.com/cd/E26502_01/html/E28984/gkoks.html#gijmp

Please let me know if you have corrections or other comments.

Re: How to repair /etc/pam.conf

Bart Smaalders — 2013-03-18T22:52:19

Had this been a real emergency, you could have restored the original
/etc/pam.conf with:

pkg revert /etc/pam.conf

 From the fine man page:

      pkg revert [-nv] [--no-be-activate] [--no-backup-be | --
      require-backup-be] [--backup-be-name name] [--deny-new-be |
      --require-new-be] [--be-name name] (--tagged tag-name ... |
      path-to-file ...)

          Revert files delivered by pkg(5) packages to  their  as-
          delivered  condition. File ownership and protections are
          also restored.

          Caution -

            Reverting some editable files to their default  values
            can  make  the  system unbootable, or cause other mal-
            functions.

          --tagged tag-name

              Revert all files tagged with  tag-name,  and  remove
              any unpackaged files or directories matching pattern
              in directories with this tag.  See "File Actions" in
              the pkg(5) manual page.


          path-to-file

              Revert the specified files.

          For all other options, see the install command above.


- Bart

Re: How to repair /etc/pam.conf

Alan Coopersmith — 2013-03-18T18:29:15

Since it's delivered with the "preserve=renamenew" attribute, look in
/etc/pam.conf.new for the packaged file, since pkg won't overwrite the
file you may have customized.

Though in this case, you may find it a bit anticlimatic, as the packaged
pam.conf file in that release is nothing but a comment telling you that
the contents have all moved to /etc/pam.d now.

How to repair /etc/pam.conf

James Litchfield — 2013-03-18T19:03:12

Through some mysterious process, I have ended up with a
zero length /etc/pam.conf.

The intriguing thing is how do I rectify this situation?

I can find the file in the package, I can do a pkg fix on the
package that contains it and I still end up with what I had before.
One possibility is that it gets built on the fly?

This does bring up a question: how does one extract a
single file from a package in a supported manner?

Jim
----

Code review: add_cronjob failing after uncleanshutdown

Tim Foster — 2013-03-14T05:56:13

hi there,

I've a short webrev here that fixes the case where a system was rebooted 
without the SMF stop-method script being called for the services that 
use the pkg5_include.sh function 'add_cronjob', causing the subsequent 
start-method script to fail.

This bug affects svc:/application/pkg/update and the new 
svc:/application/pkg/mirror services.

https://cr.opensolaris.org/action/browse/pkg/timf/add-cronjob/add_cronjob-webrev

Comments welcome,

cheers,
tim

Re: safety of the update (downgrade) operation

Danek Duvall — 2013-03-13T15:47:45


When you downgrade a package, packages that depend on it might also need to
be downgraded, and that dependency chain may cascade pretty far, depending
on how core a package it is that you're trying to downgrade.  I hope at
some point we'll be able to build most of our leaf packages on old versions
of the core, but most of our build systems can't yet handle that
effectively.

But that's just another form of not being able to move a particular package
from one version to another because of constraints other installed packages
are placing on it, such as incorporations that prevent you from moving
forward, and so on.

The problems with rename and obsolete are different.  First is that in the
case of obsolete (and rename, if nothing on the system still depends on the
old name), the package is simply removed, so there's really nothing to
update backwards from -- it's essentially just an install.  You can usually
install a non-obsolete version of a now-obsolete package (modulo other
constraints).

If you downgrade a renamed package, you can also run into the issue that
the older version and the newer (renamed) version share the same files, so
both can't be installed at the same time.  We'll tell you that there are
conflicting actions, but we don't analyze the case to tell you that it's a
downgrade-across-rename, nor do we auto-remove the new name.

Danek

safety of the update (downgrade) operation

Joe Higgins — 2013-03-12T13:29:20

Hi,

I had a general question about the pkg update operation.

With the update operation the user can pick specify a version which 
might actually be a downgrade on a installed package.

I see one caveat in the man page about

Please note that updating
           specific packages across package rename or obsolete boundaries
           is not supported.


So are they any additional scenarios WRT to downgrading packages which 
customers need to be concerned about.


Joe

15804991 option mangling and verification should bepart of the API, not the CLI client

2013-03-11T22:34:23

Author: Erik Trauschke <Erik.Trauschke< at >oracle.com>
Repository: /hg/pkg/gate
Branch: default
Latest revision: 09e276ba70c65d321c8d9f631b70bf74be5fc01d
Total changesets: 1
Log message:
15804991 option mangling and verification should be part of the API, not the CLI client

Files:
create: src/modules/client/options.py
update: src/client.py
update: src/modules/client/api_errors.py
update: src/modules/misc.py
update: src/pkg/manifests/package:pkg.p5m
update: src/po/POTFILES.in

Re: [review] 15804991 option mangling and verification should be part of the API, not, the CLI client

Erik Trauschke — 2013-03-11T22:30:09


On 03/ 8/13 03:24 PM, Erik Trauschke wrote:

I talked to Ed about this off-line and we agreed to move the code into 
misc.py since we'd have to do an inefficient search in the option lists 
anyway.

Otherwise he was fine with the changes and I'll put back the code in a bit.

Erik

Re: Fwd: Removed from hook-test-commits< at >ips.java.net

Danek Duvall — 2013-03-09T15:50:06


No idea, unless we take the message's suggestion.  But that makes little
sense, since there haven't been any messages to that list since you
subscribed.  If you get it again when you subscribe, let me know and I'll
see if I can't get some help.

Danek

Fwd: Removed from hook-test-commits< at >ips.java.net

Peter Cudhea — 2013-03-09T15:24:14

When I created a new account at java.net and then joined the new IPS java.net project, I got the following message.   Do you know what causes this?   

/peter

Begin forwarded message:


Peter Cudhea
peter.cudhea< at >oracle.com