[bug-notifications] [cswclassutils 0003635]: Support service that can't be autoenabled at first install

Mantis Bug Tracker noreply at opencsw.org
Wed Jun 3 10:47:17 CEST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://www.opencsw.org/mantis/view.php?id=3635 
====================================================================== 
Reported By:                yann
Assigned To:                bonivart
====================================================================== 
Project:                    cswclassutils
Issue ID:                   3635
Category:                   regular use
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2009-04-13 19:59 CEST
Last Modified:              2009-06-03 10:47 CEST
====================================================================== 
Summary:                    Support service that can't be autoenabled at first
install
Description: 
Some daemons can't be launched at all at first install without a bit of
manual configuration, that the case of imapproxy which require an imap
server to be given in imapproxy configuration file.

Currently, cswclassutils cswinitsmf will always tries to start the daemon
if autoenable_daemons=yes, for cswimapproxy this would result in a service
in maintenance state that would need to be cleared.

It would be nice to have support for this case, the service can't be
launched at first install, but once it is configured and enabled by the
administrator, it has to be re-launched at each upgrade.
====================================================================== 

---------------------------------------------------------------------- 
 (0005991) bonivart (manager) - 2009-04-21 17:17
 http://www.opencsw.org/mantis/view.php?id=3635#c5991 
---------------------------------------------------------------------- 
Isn't this normally handled by the start script? Something like:

[ -f someconffile ] && startservice 

---------------------------------------------------------------------- 
 (0005997) yann (reporter) - 2009-04-21 21:12
 http://www.opencsw.org/mantis/view.php?id=3635#c5997 
---------------------------------------------------------------------- 
The script already has this check, but as your script will always try to
enable the service (if autoenable_daemons != no), the init script will exit
and the imapproxy service will go in maintenance mode from SMF point of
view.

It would be cleaner to have it not started at all at the first install. 

---------------------------------------------------------------------- 
 (0006125) yann (reporter) - 2009-05-17 16:57
 http://www.opencsw.org/mantis/view.php?id=3635#c6125 
---------------------------------------------------------------------- 
Hi Peter,

Any news of this feature request ? 

---------------------------------------------------------------------- 
 (0006211) bonivart (manager) - 2009-05-28 10:24
 http://www.opencsw.org/mantis/view.php?id=3635#c6211 
---------------------------------------------------------------------- 
I think I will enable this via another tweak in the init script. OK? 

---------------------------------------------------------------------- 
 (0006214) bonivart (manager) - 2009-05-28 14:44
 http://www.opencsw.org/mantis/view.php?id=3635#c6214 
---------------------------------------------------------------------- 
I have put in an AUTOENABLE tweak to the init script, if it's no or false
the service will not be enabled.

http://mirror.opencsw.org/testing/cswclassutils-1.12,REV=2009.05.28-SunOS5.8-all-CSW.pkg.gz


---------------------------------------------------------------------- 
 (0006240) skayser (administrator) - 2009-06-01 17:37
 http://www.opencsw.org/mantis/view.php?id=3635#c6240 
---------------------------------------------------------------------- 
Thanks for adding this feature, just tested it and ran into a small hitch.
The tr used to translate from upper to lower, doesn't work with multibyte
locales and thus the script fails when running in for example en_US.UTF-8.
Also there is a space missing in one of the test clauses.

# pkgparam CSWcswclassutils VERSION
1.14,REV=2009.05.29

# locale
LANG=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

# pkgutil -t http://mirror.opencsw.org/opencsw/testing -u stunnel
...
Creating service script in /var/opt/csw/svc/method/svc-cswstunnel ...
Creating manifest ...
Configuring service in SMF ...
CSWstunnel is using Service Management Facility. The FMRI is
svc:/network/cswstunnel:default
Bad string
/usr/sadm/install/scripts/i.cswinitsmf: test: ] missing

Transcript of the last part with set -x enabled:

AUTOENABLE=yes
+ grep ^#AUTOENABLE /etc/opt/csw/init.d/cswstunnel
+ [ #AUTOENABLE no ]
+ grep ^#AUTOENABLE /etc/opt/csw/init.d/cswstunnel
+ awk {print $2}
+ tr -s [:upper:] [:lower:]
Bad string
AUTOENABLE=
+ [ yes = yes -a  != no -a  != false]
/usr/sadm/install/scripts/i.cswinitsmf: test: ] missing

Note the "Bad string" warning and the empty AUTOENABLE afterwards. test
complains because there is a space missing before the closing bracket.

When using /usr/xpg4/bin/tr in i.cswinitsmf instead of /bin/tr,
installation works fine. See also tr(1).

Note:  /usr/bin/tr  supports  character   class
expressions  only  in  singlebyte  locales. Use
/usr/xpg4/bin/tr to support  these  expressions
in any locale. 

---------------------------------------------------------------------- 
 (0006246) bonivart (manager) - 2009-06-02 19:17
 http://www.opencsw.org/mantis/view.php?id=3635#c6246 
---------------------------------------------------------------------- 
Oops, sorry about that. Fixed the space and switched to xpg4/tr. Try:

http://mirror.opencsw.org/testing/cswclassutils-1.15,REV=2009.06.02-SunOS5.8-all-CSW.pkg.gz


---------------------------------------------------------------------- 
 (0006252) skayser (administrator) - 2009-06-03 01:10
 http://www.opencsw.org/mantis/view.php?id=3635#c6252 
---------------------------------------------------------------------- 
Works, thanks. What do you think about somehow evaluating the AUTOENABLE
for classic init scripts also? From looking at the script, for $smf = no it
will say "Starting $service" and try to run /etc/init.d/$service.

Taken stunnel, it doesn't make sense to run it without a proper
configuration, that's why i use AUTOENABLE. Currently I have added a test
-f conffile || exit 0 to its init script, but i was thinking about
extending it with an error message like "stunnel configuration missing.
Exiting.". Only with i.cswinitsmf this won't be seen by the user.

# grep -n "/etc/init.d/\$service start"
/usr/sadm/install/scripts/i.cswinitsmf
298:      /etc/init.d/$service start > /dev/null 2>&1

So if you could skip the /etc/init.d/$service start if AUTOENABLE says so,
we would just have to make sure that our init scripts let users know why
they bail out (like with the missing configuration). This way, upon reboot
they would know why a service could not be started, but they wouldn't get a
"Starting $service" with no immediate effect upon installation (like it is
now). 

---------------------------------------------------------------------- 
 (0006257) bonivart (manager) - 2009-06-03 10:47
 http://www.opencsw.org/mantis/view.php?id=3635#c6257 
---------------------------------------------------------------------- 
I thought about it but I would have to choose between just skipping the
start at end of install or not creating the rc-links and skipping start.
The first would seem clean at install but after a reboot it would try to
start it again, is that ok? The second would perhaps be ok at first but
after the user has fixed the config they would have to create the rc-links
themselves which is not very nice.

It's hard to implement it perfectly without the knowledge of state that
SMF brings to the table.

What do you think? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-13 19:59 yann           New Issue                                    
2009-04-21 17:15 bonivart       Status                   new => assigned     
2009-04-21 17:15 bonivart       Assigned To               => bonivart        
2009-04-21 17:17 bonivart       Note Added: 0005991                          
2009-04-21 21:12 yann           Note Added: 0005997                          
2009-05-17 16:57 yann           Note Added: 0006125                          
2009-05-28 10:24 bonivart       Note Added: 0006211                          
2009-05-28 14:44 bonivart       Note Added: 0006214                          
2009-06-01 17:37 skayser        Note Added: 0006240                          
2009-06-02 19:17 bonivart       Note Added: 0006246                          
2009-06-03 01:10 skayser        Note Added: 0006252                          
2009-06-03 10:47 bonivart       Note Added: 0006257                          
======================================================================




More information about the bug-notifications mailing list