Mantis - cacertificates
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3910 packaging minor always 2009-09-21 14:06 2009-11-22 12:51
Reporter: maciej Platform:  
Assigned To: yann OS:  
Priority: normal OS Version:  
Status: closed Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0003910: Postinstall script fails for ca_certificates when /opt/csw is read-only
Description: The postinstall script tries to write to the /opt/csw directory and fails with an error. It doesn't break anything, it's just a needless error message.
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:
Issue History
Date Modified Username Field Change
2009-09-21 14:06 maciej New Issue
2009-10-11 14:55 yann Assigned To => yann
2009-10-11 14:55 yann Status new => feedback
2009-10-11 14:55 yann Additional Information Updated
2009-10-11 14:56 yann Note Added: 0006832
2009-10-11 14:56 yann Additional Information Updated
2009-10-11 21:37 maciej Note Added: 0006835
2009-10-11 23:34 yann Note Added: 0006841
2009-10-12 09:49 maciej Note Added: 0006844
2009-10-12 23:27 yann Note Added: 0006851
2009-10-13 00:17 maciej Note Added: 0006852
2009-11-01 02:29 yann Note Added: 0006929
2009-11-01 02:29 yann Status feedback => resolved
2009-11-01 02:29 yann Resolution open => fixed
2009-11-22 12:51 yann Status resolved => closed

Notes
(0006832)
yann   
2009-10-11 14:56   
Can you explain me the use case ?
If /opt/csw is read-only, how can you first install the ca_certificates package ?
(0006835)
maciej   
2009-10-11 21:37   
There is the global zone and there are non-global zones. The package is being installed from the global zone. All the other zones inherit the package. It goes something like this:

- The global zone:
  - the preinstall scripts are being run
  - the files get extracted and placed in all the directories on the global zone
  - the postinstall scripts are being run
- Other zones:
  - preinstall
  - all the files that weren't inherited from the global zone are being placed on the disk
  - postinstall

Most of the files are put on the disk from within the global zone, but pre/postinstall scripts are being run in every zone.
(0006841)
yann   
2009-10-11 23:34   
Hmm, I am not sure what is the best way to handle this problem.

In fact, the package should not launch the postinstall code in a zone where /opt/csw or /opt/csw/etc or /opt/csw/etc/ssl or /opt/csw/etc/ssl/certs is shared with the global zone.

I could try to detect lofs mount using the output of the mount command but I wonder if there is a cleaner solution. Any idea ?
(0006844)
maciej   
2009-10-12 09:49   
Using /etc/opt/csw instead would be the best solution.

http://wiki.opencsw.org/configuration-directory-migration [^]

There are example implementations of how to go about the migration.
(0006851)
yann   
2009-10-12 23:27   
I read the thread but I still don't understand if a consensus has been reached.

According to the standard:

 /opt/csw/etc
    Global Configuration files. (Machine-local conf files should go in
    /etc/opt/csw/[softwarename] or /etc/opt/csw)

It can be discussed but I would think valid certificates are rather something that are global and should be shared in a shared /opt/csw scenario (either nfs or zone).


Honestly I personally prefer the "everything by default in /etc/opt/csw and lofs mount /etc/opt/csw on opt/csw/etc for those who want" scenario but I prefer to follow the standards. So has the decision been taken on the /etc/opt/csw move ?
(0006852)
maciej   
2009-10-13 00:17   
If by making the decision you mean Phil saying "we should make it the default", this e-mail from the maintainers is relevant:

http://lists.opencsw.org/pipermail/maintainers/2009-June/002885.html [^]

There were discussion about how to migrate existing configuration, but not about whether the configuration should be moved or not. You could ask about this specific case on the mailing list if you're still unsure.
(0006929)
yann   
2009-11-01 02:29   
Interesting thread, I think I will move all my packages to this new schema.
However it's not a quick task as I will need to test and warn users.

So for now I just uploaded a new ca_certificates packages (20091101,REV=2009.11.01) which solves this bug with a dirty hack (try to write in /opt/csw to check if it is writeable, if so don't try to update certificates list), and in a second time I will do the /etc/opt/csw move for ca_certificates and all other packages I maintain.