gridcf / gct

Grid Community Toolkit
Apache License 2.0
47 stars 30 forks source link

Update default run directory from /var/run to /run #146

Closed ellert closed 3 years ago

ellert commented 3 years ago

Filesystem Hierarchy Standard 3.0 says about /var/run: "This directory was once intended for system information data describing the system since it was booted. These functions have been moved to /run."

Using /var/run in systemd unit files and tmpfiles.d config files results in warnings in the logs:

Dec 23 12:42:25 localhost.localdomain systemd[1]: /usr/lib/systemd/system/myproxy-server.service:16: PIDFile= references a path below legacy directory /var/run/, updating /var/run/myproxy-server/myproxy.pid → /run/myproxy-server/myproxy.pid; please update the unit file accordingly.

/usr/lib/tmpfiles.d/myproxy-server.conf:1: Line references path below legacy directory /var/run/, updating /var/run/myproxy-server → /run/myproxy-server; please update the tmpfiles.d/ drop-in file accordingly.

msalle commented 3 years ago

Hi, in principle fine, but just as a general thought, shouldn't we ideally use %_rundir in the specfile and add a configure flag? https://www.gnu.org/prep/standards/html_node/Directory-Variables.html talks about runstatedir (should be in autotools 2.70 and up but that's just released, so perhaps we should wait a while).

fscheiner commented 3 years ago

@msalle @ellert

A few more comments:

* at least [packaging/package-output/hpn_isshd-gsi.7.5p1c.patch](https://github.com/gridcf/gct/blob/master/packaging/debian/gsi-openssh/debian/patches/hpn_isshd-gsi.7.5p1c.patch),  also contains `/var/run`.

* Likewise for [packaging/debian/gsi-openssh/debian/gsi-openssh-server.init](https://github.com/gridcf/gct/blob/master/packaging/debian/gsi-openssh/debian/gsi-openssh-server.init) and [packaging/debian/gsi-openssh/debian/gsi-openssh-server.postinst](https://github.com/gridcf/gct/blob/master/packaging/debian/gsi-openssh/debian/gsi-openssh-server.postinst) although I'm not sure they're being used.

Let's keep out GSI-OpenSSH for now. As per https://github.com/gridcf/gct/issues/67#issuecomment-786074599 things will or could change for GSI-OpenSSH in the GCT anyhow.

* shouldn't we at some point update [myproxy/source/VERSION](https://github.com/gridcf/gct/blob/master/myproxy/source/VERSION) to get it back in sync?

I'll try to update that file accordingly and push my changes to @ellert's branch.

* Finally 3 out of the 4 files in  but they don't even end up in the GCT.

What do you mean with that @msalle, is there something missing in this question?

fscheiner commented 3 years ago

Ok, myproxy/source/VERSION is now in sync with the history as logged in the corresponding RPM spec file. I cross-checked the entries with the commits from https://github.com/ellert/gct/blame/var-run-is-run/packaging/fedora/myproxy.spec so spec file related entries should not got included in my myproxy/source/VERSION. Please correct if you still find some.

msalle commented 3 years ago
  • Finally 3 out of the 4 files in but they don't even end up in the GCT.

What do you mean with that @msalle, is there something missing in this question?

oops, had a [](https://) link but forgot the name itself (i.e. between the []. Fixed now (should have been myproxy/oauth/source/conf/).

ellert commented 3 years ago

Since an other PR for myproxy was merged I had to bump the version number for that. That meant that this PR then had to be rebased to resolve the conflicts. I cherrypicked the update of the VERSION file directly to master.

fscheiner commented 3 years ago
* Finally 3 out of the 4 files in [myproxy/oauth/source/conf/](https://github.com/gridcf/gct/tree/master/myproxy/oauth/source/conf) have `/var/run`: but they don't even end up in the GCT.

myproxy-oauth-epel5 can be removed anyhow I think. But myproxy-oauth-2.4-deb is used in here: https://github.com/gridcf/gct/blob/master/packaging/debian/myproxy-oauth/debian/rules and the remaining two are used in https://github.com/gridcf/gct/blob/master/packaging/fedora/myproxy-oauth.spec, though from the logic only myproxy-oauth-2.4 seems to be for newer Fedora/EPEL package sources (i.e. at least Fedora 18 and EPEL 7), so myproxy-oauth can be removed, too (plus update to the RPM spec file), I assume.

But maybe let's do that in a separate PR, as "myproxy-oauth" is a separate package anyhow.

@msalle, @ellert: Do you agree?

msalle commented 3 years ago

Hi @fscheiner I agree it's better done in a separate PR. We could ask also @jbasney whether it's still in use anywhere.

jbasney commented 3 years ago

As far as I know, that myproxy-oauth Python code was only used inside Globus Connect installations, so I think there's no need to keep it for GCT.