0004075: cswinitsmf should refuse to create an FMRI with a dot in the name

(0007081)
bonivart (developer)
2009-12-10 23:34

Is it the service script name that can't have dots in it or is it the FMRI path or both?

Shouldn't this be caught by GAR (checkpkg) instead? If someone packages something in violation with Sun standards it shouldn't be released. If I "fix" it in cswinitsmf it will lead to unpredictable results like aborting or changing the name/path on the fly.

Better to catch it earlier.

(0007083)
maciej (manager)
2009-12-11 12:39

I think it's the FMRI.

On the cswclassutils side there should be at least a warning printed to the screen.

How would checkpkg reliably detect this problem?

(0007084)
bonivart (developer)
2009-12-11 17:07

I think in general we shouldn't release faulty packages, if the user has unknown local problems we can't do much about that but hopefulle handle it with some grace but this is known to be in violation and shouldn't be released.

We have decided to have all start scripts (used by cswinitsmf) in /etc/opt/csw/init.d. Checkpkg could grep the script for an illegal FMRI. If it's the default (commented out or not) "network" it's ok but if it's something custom it shouldn't contain dots.

Ben was talking about remaking checkpkg (which is a total mess) into a modular wrapper so many of us could contribute with separate tests that are executed by the new checkpkg. It just needs a well defined interface to the modules what to send as arguments and what to expect in return.

(0007098)
maciej (manager)
2009-12-18 18:49

I was thinking about the stage in which the maintainer tests the package before putting it into testing. At this stage, it would be very convenient for cswclassutils to report what the problems is.

(0007109)
bonivart (developer)
2009-12-20 19:13

Ok, I get that. I could issue a big fat warning about it.

(0007179)
bonivart (developer)
2010-01-06 00:56

How about making a modular mini test for this?

(0007180)
maciej (manager)
2010-01-06 01:06

I like the idea. It doesn't mean I don't think that cswclassutils shouldn't check for it; I think that there's a check needed in cswclassutils, and an additional one in checkpkg to catch the issue as early as possible.

(0007192)
bonivart (developer)
2010-01-07 17:38

I agree with adding a warning to cswinitsmf, the problem is already in the package and it can't be handled much better or should i filter out dots from the FMRI with sed before using it? Still issue a big warning though.

I think it's most important to not let new and updated packages pass with known problems. Everything we find we should add a test for so it can't pass again.

(0007193)
maciej (manager)
2010-01-08 12:17

I thinking what should the checkpkg-level test do here. It can examine the prototype, look for the cswinitsmf class, and report an error if there was a dot in the last part of the filename:

/foo/bar_baz (good)
/foo.bar/baz (good)
/foo/bar.baz (bad)

The assumption would be that the file name and FMRI are the same.

(0007425)
bonivart (developer)
2010-02-11 19:03

Version 1.33 of cswclassutils is in testing and this is what happens when you have a dot (or several dots) in the FMRI:

[ verifying class <cswusergroup> ]
Installing class <cswinitsmf> ...
WARNING! FMRI path contained an illegal dot (removed)
New FMRI path: foo
Creating /var/opt/csw/svc/manifest/foo ...
Creating service script in /var/opt/csw/svc/method/svc-cswspamd ...
Creating manifest ...
Configuring service in SMF ...
CSWspamassassin is using Service Management Facility. The FMRI is svc:/foo/cswspamd:default
Enabling svc:/foo/cswspamd ...
[ verifying class <cswinitsmf> ]

(0007622)
bonivart (developer)
2010-03-10 20:08

Awaiting next release.

Notes
(0007081) bonivart (developer) 2009-12-10 23:34	Is it the service script name that can't have dots in it or is it the FMRI path or both? Shouldn't this be caught by GAR (checkpkg) instead? If someone packages something in violation with Sun standards it shouldn't be released. If I "fix" it in cswinitsmf it will lead to unpredictable results like aborting or changing the name/path on the fly. Better to catch it earlier.

(0007083) maciej (manager) 2009-12-11 12:39	I think it's the FMRI. On the cswclassutils side there should be at least a warning printed to the screen. How would checkpkg reliably detect this problem?

(0007084) bonivart (developer) 2009-12-11 17:07	I think in general we shouldn't release faulty packages, if the user has unknown local problems we can't do much about that but hopefulle handle it with some grace but this is known to be in violation and shouldn't be released. We have decided to have all start scripts (used by cswinitsmf) in /etc/opt/csw/init.d. Checkpkg could grep the script for an illegal FMRI. If it's the default (commented out or not) "network" it's ok but if it's something custom it shouldn't contain dots. Ben was talking about remaking checkpkg (which is a total mess) into a modular wrapper so many of us could contribute with separate tests that are executed by the new checkpkg. It just needs a well defined interface to the modules what to send as arguments and what to expect in return.

(0007098) maciej (manager) 2009-12-18 18:49	I was thinking about the stage in which the maintainer tests the package before putting it into testing. At this stage, it would be very convenient for cswclassutils to report what the problems is.

(0007109) bonivart (developer) 2009-12-20 19:13	Ok, I get that. I could issue a big fat warning about it.

(0007179) bonivart (developer) 2010-01-06 00:56	How about making a modular mini test for this?

(0007180) maciej (manager) 2010-01-06 01:06	I like the idea. It doesn't mean I don't think that cswclassutils shouldn't check for it; I think that there's a check needed in cswclassutils, and an additional one in checkpkg to catch the issue as early as possible.

(0007192) bonivart (developer) 2010-01-07 17:38	I agree with adding a warning to cswinitsmf, the problem is already in the package and it can't be handled much better or should i filter out dots from the FMRI with sed before using it? Still issue a big warning though. I think it's most important to not let new and updated packages pass with known problems. Everything we find we should add a test for so it can't pass again.

(0007193) maciej (manager) 2010-01-08 12:17	I thinking what should the checkpkg-level test do here. It can examine the prototype, look for the cswinitsmf class, and report an error if there was a dot in the last part of the filename: /foo/bar_baz (good) /foo.bar/baz (good) /foo/bar.baz (bad) The assumption would be that the file name and FMRI are the same.

(0007425) bonivart (developer) 2010-02-11 19:03	Version 1.33 of cswclassutils is in testing and this is what happens when you have a dot (or several dots) in the FMRI: [ verifying class <cswusergroup> ] Installing class <cswinitsmf> ... WARNING! FMRI path contained an illegal dot (removed) New FMRI path: foo Creating /var/opt/csw/svc/manifest/foo ... Creating service script in /var/opt/csw/svc/method/svc-cswspamd ... Creating manifest ... Configuring service in SMF ... CSWspamassassin is using Service Management Facility. The FMRI is svc:/foo/cswspamd:default Enabling svc:/foo/cswspamd ... [ verifying class <cswinitsmf> ]

(0007622) bonivart (developer) 2010-03-10 20:08	Awaiting next release.

Relationships

OpenCSW Bug Tracker