Bug 636066

What are you trying to edit in it and why?

(The RPM does not currently permit you to edit the file - if you do, any changes will be lost next time you update the package.)

With my cluster configuration, I need to add 'drbd' to the 'Required-Start' line.

I think it's a poor design that expects or relies on the script to never be edited. Particularly init scripts as they've got the LSB headers specifically designed to be easily user-editable.

Might I suggest the following;

- Restore 0755
- On update, check for differences in the LSB header (line 1 through 16 in the current release) and copy those changes into the new/updated init script.
- Put a warning that any changes below the header will be not be preserved across updates.

That should satisfy the "don't edit the script" desire, which I can understand and agree with, while still allowing the user to take advantage of the mechanisms designed into the header.

Cheers

Just to clarify;

If you protect/restore the sections between '### BEGIN INIT INFO' and '### END INIT INFO' would not be sufficient. The '# chkconfig: - 24 76' may legitimately be modified as well.

Perhaps diff'ing from line 1 to '### END INIT INFO'?

Enough comments from me. :)

As supplied the initscript is not meant to be edited.  Some other solution must be found - e.g. splitting it into two pieces, one which is editable and one which isn't, or putting the settings that may want to be edited elsewhere (sysconfig / defaults).

(The editable bit could then be handled by rpm's 'config' tag, preserving a copy of it whenever an update replaced it if it had been edited.)

Normally, I'd agree that the editable bits should be elsewhere. However, this is a fundamental system standard. It would be complicated, to understate it, if clvmd's init script had a different method of handing chkconfig than the rest of the system's init scripts.

This is relevant, for those viewing that may not be familiar with LSB.

http://fedoraproject.org/wiki/Packaging/SysVInitScript

"Initscripts must not be marked as %config files.

Although init files live in /etc, they are scripts to be executed, not configured. Any configuration should be made available through /etc/sysconfig/<service> rather than in the init script itself. "

That's a MUST.

Setting to 0755 is only a SHOULD - and if I'd done that, this configuration problem would not yet have been noticed.

So those guidelines are pretty clear that you should not be attempting to edit this file, but instead we should be providing the facilities to make the change you need some other way e.g. in sysconfig (or through some drbd package).

The 0755 is itself in conflict with the 'don't edit this' requirement and IMHO should be changed to 0555 in those guidelines.

I understand what you're saying, but then one would have to argue that most of the other init package maintainers should change how they handle changes to start ordering. It also, then, strikes me as the whole LSB structure being fatally flawed.

To use my example; I've needed to make several changes to the initialization boot order, not just with clvmd. To explain why would require some length, so may I point you to my docs? This isn't specific to CLVM, but shows an example of where editing the init script's LSB header and config file is required:

http://bit.ly/bg6UkN [1]

For CLVM specifically, I want to ensure a sane boot order. Specifically that it does not start until 'cman' and 'drbd' are both running. The logic and method are explained here:

http://bit.ly/9VkYit [2]

If clvmd's start/stop ordering should be configured outside of the init script itself, then the solution should be structured to support init scripts in general. Given that there is a fair bit of momentum behind the current system, I am not sure if it is feasible to change something so fundamental. I would argue that, if the LSB mechanism can't be generally changed, that it would be best to come up with a solution that can work with the current system.

Perhaps a pre and post script that checks for a non-standard configuration (be it in the init script itself and/or in an '/etc/sysconfig/...' file). In pre, copy out non-standard settings to the sysconfig file and then in post, check the settings in that file and use them to re-write the LSB header.

I could probably write a little perl script that would sanely handle this. I could use '/etc/sysconfig/clvmd.boot.conf' or something similar.

Digimer

1. http://wiki.alteeve.com/index.php/Two_Node_Fedora_13_Cluster_-_Xen-Based_Virtual_Machine_Host_on_DRBD%2BCLVM#Make_xend_play_nice_with_clustering
2. http://wiki.alteeve.com/index.php/Two_Node_Fedora_13_Cluster_-_Xen-Based_Virtual_Machine_Host_on_DRBD%2BCLVM#Altering_Daemon_Start_Order

The LSB 4.0 (and prior versions) state:

"This specification does not define the concept of a package upgrade. Implementations may do different things when packages are upgraded, including not replacing an init script if it is marked as a configuration file, particularly if the file appears to have been modified since installation. ... Applications should design their installation procedure and init scripts to be robust in the face of such behavior." [1]

So I would argue, if some method of storing and restoring changes is not to be implemented, that the init script not be replaced if it has an mtime/md5/etc. different from known prior versions available on the host OS version.

This [2] Fedora draft guide seems to indicate that new syntax will be made available for RPMs to not replace existing files, using '/etc/init.d' as an example.

I'm open to suggestions.

Digimer

1. http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
2. http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s03.html

The initscript has to be replaced on update because it contains script which we do seem to change quite a bit: we cannot support having people running old copies of it.  That's why I'm saying it should be split in two - the bits people can edit and carry forward to later releases with the config mechanism, and the bits they can't.

What is your thought then on the script like what I recommended in comment 13? I could probably have a working example in an hour or so after work today.

files in /etc are by definition config files.
Config files can be used and changed to effect system configuration.

Any upgrade process should take into account the fact that some files in /etc may be changed.

If the init files only contained scripts I would agree with you.
The trouble is that the init file contain config information that can reasonably change.

I can understand your desire to stick with the Fedora spec.
But you should stick with it.
Fedora says the files should be 0755.

Alasdair,

I've finished the first version of an LSB header scanner/restorer. It's a bit more involved than I anticipated yesterday as I decided to make it a general-purpose tool

I've called it 'lsb-scanner', and it uses your idea of storing the information in '/etc/sysconfig'. It has two modes of operating, specifically designed for use in RPMs. 

Pre-Scan mode:

lsb_scanner -m pre -p clvmd

This will read the LSB header and record values in '/etc/sysconfig/lsb_config.clvmd.conf' as 'variable: value' pairs. 

After this, you can replace the init script. After, you re-run the program in 'post-write' mode.

lsb_scanner -m post -p clvmd

This will read in the '/etc/sysconfig/lsb_config.clvmd.conf', if it exists. If it does not (as in the case of a fresh install), lsb_scanner simply exits. If it is found, then the contained values are read into memory. Then the (new) init script is read and *if* a difference is found, a backup is made of the new init script as '/etc/sysconfig/lsb_config.clvmd.init.backup.<timestamp>'. Once the backup is made, the actual init script is written back out with the restored LSB header values.

The program is entirely self-contained. There is a man page in the source tarball, but it's for your benefit and doesn't need to be included. The script itself is 14 KiB and has no special requirements beyond base perl.

It is released under the GPL v2+. This should conform with Red Hat/Fedora requirements. I've signed the Fedora/RH agreement, but I'm at a loss for finding the link. If you like the program, I will dig it up tomorrow.

The project page is:
- http://github.com/digimer/lsb-scanner

The website, such that it is, with the tarball download is:
- http://wiki.alteeve.com/index.php/Lsb-scanner

Digimer

Found it; https://admin.fedoraproject.org/accounts/user/view/digimer (not sure what would have been a better link, that will complain about the CSRF token being missing).

Created attachment 449117 [details]
*TEST* patch to lvm2 v2.02.73 spec file

***THIS IS NOT A PROPOSED PATCH***

This is a slightly modified lvm2.spec file. It will create a slightly modified lvm2-cluster RPM that will download the lsb-scanner to /tmp/ in %pre, then run it in "Pre Scan" mode (backing up any user-made changes to the LSB header). It then runs it again in %post in "Post Write" mode.

To test it's functionality, change something in the /etc/init.d/clvmd script (ie: add 'drbd' to 'Required-Start'. The run 'rpm -Uvh --force lvm2-cluster-2.02.73-2.fc13.x86_64.rpm'. After it finishes, the user-made changes should remain and the original permissions should stay unchanged.

If this is an acceptable solution, then some manner of making lsb-scanner available in the RPM is suggested.

Can I get an update on this please? Thanks.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.