Attention is currently required from: fixeria, lynxis lazus, msuraev.

View Change

1 comment:

• File debian/postinst:

  • Patch Set #8, Line 18: # Fix permissions of previous (root-owned) install (OS#4107)

    Please note that changing the user the Osmocom programs run as, from root to the new osmocom user, is a lot of effort. It affects lots of repositories, and I'm trying to do it consistently across all of them. So if we make such a change here, we would also need to do it with the other repositories (and for many the related changes were already merged: https://gerrit.osmocom.org/q/topic:nonroot+is:merged). The issue has also been open for 5 years at this point with previous attempts stuck as in WIP due the scope of having to adjust all repositories (and making sure it doesn't affect OE, ...), and I would be happy to have it finished up: https://osmocom.org/issues/4107

    With that being said:

    It would be great to show a warning or something, so the user know those file has been changed.

    One way to do it without introducing additional complexity could be `chown -v`, and `chmod -v`. But that also causes a line to be printed if the permissions do not change.

    ```
    # chown -v osmocom:osmocom /etc/osmocom/osmo-mgw.cfg
    changed ownership of '/etc/osmocom/osmo-mgw.cfg' from root:root to osmocom:osmocom
    # chown -v osmocom:osmocom /etc/osmocom/osmo-mgw.cfg
    ownership of '/etc/osmocom/osmo-mgw.cfg' retained as osmocom:osmocom
    # chmod -v 0660 /etc/osmocom/osmo-mgw.cfg
    mode of '/etc/osmocom/osmo-mgw.cfg' retained as 0660 (rw-rw----)
    ```

    Can't you detect if this is an upgrade and from which version you're upgrading from?

    This doesn't really work for the nightly packages, and it would also mean that we need to hardcode the version that introduces this change for every repository into this postinst file. I'd rather avoid this effort, as mentioned this is already a big undertaking. Additionally, the more logic we put into such postinst files, the more likeyl they are to have bugs... IMHO it's better to just run this unconditionally, if we have to do this (and we do, because otherwise we break the feature that allows writing back config files).

    Since similar patches were already +2'd and merged, I suggest we do it the same way here.

To view, visit change 30094. To unsubscribe, or for help writing mail filters, visit settings.