Mantis - alternatives
Viewing Issue Advanced Details
4424 upgrade minor always 2010-05-20 22:46 2013-08-25 21:40
dkohfield  
phil  
normal  
closed  
fixed  
none    
none  
0004424: CSWsudo and CSWalternatives interaction breaks sudo installs on SPARC
Upgraded from a blastwave installation, which for all practical purposes was a clean install on the system in question:

  SunOS neon 5.9 Generic_118558-05 sun4u sparc SUNW,Sun-Fire-V240

After the upgrade/install, sudo was not working.

Trouble-shooting included uninstalling and reinstalling CSWsudo and all of its dependencies. Using 'pkg-get -i sudo' installed all dependencies, then generated the following error as the CSWsudo package was installed:

  /opt/csw/bin/sudo.minimal
  /opt/csw/share/doc/sudo/license
  [ verifying class <none> ]
  /opt/csw/bin/sudoedit.minimal <linked pathname>
  Registering 'sudo' alternative /opt/csw/bin/sudo.minimal ...
  ERROR: /opt/csw/sbin/alternatives could not be found
  [ verifying class <cswalternatives> ]

This is despite CSWalternatives having been successfully (?) installed as a dependency, and '/opt/csw/sbin/alternatives' being present (though not executable).

The net result is that no symlink, or symlink chain is created along the lines of:

  /opt/csw/bin/sudo -> \
   /etc/opt/csw/alternatives/sudo -> \
   /opt/csw/bin/sudo.minimal

Another system upgraded roughly 2-3 months ago has this symlink chain in place. The version of CSWalternatives is different. On the working system, 'pkginfo -l CSWalternatives' produces:

   PKGINST: CSWalternatives
      NAME: alternatives - Alternatives engine from Red Hat chkconfig-1.3.30c
  CATEGORY: application
      ARCH: sparc
   VERSION: 1.3.30c,REV=2010.02.18
    VENDOR: http://www.sfr-fresh.com/unix/privat/ [^] packaged for CSW by Dagobert Michelsen
    PSTAMP: dam@build8s-20100218134904
  INSTDATE: Mar 31 2010 13:08
   HOTLINE: http://www.opencsw.org/bugtrack/ [^]
     EMAIL: dam@opencsw.org
    STATUS: completely installed
     FILES: 12 installed pathnames
                   1 shared pathnames
                   7 directories
                   3 executables
                 111 blocks used (approx)

On the non-working system, 'pkginfo -l CSWalternatives' produces:

   PKGINST: CSWalternatives
      NAME: alternatives - an implementation of linux-style alternatives choice mgr
  CATEGORY: system
      ARCH: all
   VERSION: 1.0,REV=2009.10.17
    VENDOR: http://www.opencsw.org [^] written and packaged for CSW by Philip Brown
    PSTAMP: cswalternatives v1.0
  INSTDATE: May 20 2010 11:52
   HOTLINE: http://www.opencsw.org/bugtrack/ [^]
     EMAIL: phil@opencsw.org
    STATUS: completely installed
     FILES: 3 installed pathnames
                   2 executables
                  26 blocks used (approx)
Quick fix:

  ln -s /opt/csw/bin/sudo.minimal /opt/csw/bin/sudo
Issue History
2010-05-20 22:46 dkohfield New Issue
2010-05-21 01:24 phil Status new => assigned
2010-05-21 01:24 phil Assigned To => phil
2010-05-21 01:30 phil Note Added: 0007937
2010-05-21 01:30 phil Status assigned => resolved
2010-05-21 01:30 phil Resolution open => fixed
2010-05-21 01:32 phil Note Added: 0007938
2013-08-25 13:51 pfelecan Note Added: 0010541
2013-08-25 13:51 pfelecan Status resolved => closed
2013-08-25 21:40 dam Note Added: 0010546

Notes
(0007937)
phil   
2010-05-21 01:30   
Thank you for taking the time to fill out a very complete bug report.
A new package has been pushed out, and should be reaching the mirrors shortly.
(0007938)
phil   
2010-05-21 01:32   
btw: a quicker, more effective fix than your suggested "quick fix", would have been to simply add executable perms to the alternatives script, and run it :)
I believe that

chmod 0755 /opt/csw/sbin/alternatives
alternatives -auto sudo

should have fixed it up for you.
(0010541)
pfelecan   
2013-08-25 13:51   
Being so old I think that it was fixed but the maintainer forgot to close the issue. If it's not the case, please re-open with additional information.
(0010546)
dam   
2013-08-25 21:40   
sudo does not use the alternatives mechanism any more as the ldap-capable library can now be enabled via a configuration directive in sudo.conf.

Peter, as you are probably reinstantiating the RedHat implementation it is most likely that the issue will reoccur, would you mind doublechecking that it is gone? Otherwise we probably need some more fixing.