fetch-crl @3.0.14: new submission

[petrrr]

This is another "Globus related" submission. Thanks for reviewing it!

fetch-crl @3.0.12 (security, net)

Description:          The fetch-crl utility will retrieve certificate revocation lists (CRLs) for a set of installed trust
                      anchors, based on crl_url files or IGTF-style info files. It will install these for use with
                      OpenSSL, NSS or third-party tools.
Homepage:             http://wiki.nikhef.nl/grid/FetchCRL3

Platforms:            darwin
License:              Apache-2
Maintainers:          dennisvd@nikhef.nl, openmaintainer@macports.org

Again, I CC Dennis and Adam (same reasoning as for ticket #41532). For (co-)maintainer applies the same.

The changes with respect to Dennis' former version:

• update to 3.0.12;
• add openmaintainer;
• add noarch; This are perl scripts, so this should be okay;
• add license, long_description, livecheck;
• some further edits: minor format changes, destroot;

Doubts:

The scripts use System perl (/usr/bin/perl) so no dependency. Not sure if this is save and practise for MacPorts.

[petrrr]

this is for files

[petrrr]

It looks like I made a copy paste error here. Please delete fetch-crl, @3.0.12 and add dennisvd@….

[skymoo (Adam Mercer)]

A couple of comments:

1. With other ports that use launchd we name the plist file: org.macports.${port}.plist as to not interfere with upstream. May make sense to do this here.
2. I'm not sure I like the idea of the port running launchctl. In other ports that use launchd we leave the loading of the plist up to the user, MacPorts provides the load and unload commands that can be used to do this. I'd prefer seeing it work this way.

[petrrr]

Thanks for the comments on lunched, have little experience on this. Could you point me to some port using it as you describe?

[skymoo (Adam Mercer)]

Apologies but I'm not very familer with launchd either, I'd recommend emailing the list and asking for advice on how best to deal with a launchd plist.

[ryandesign (Ryan Carsten Schmidt)]

The distfiles line should be deleted since the default will work fine. The plist shouldn't be listed there because it's going to be in the files directory, not downloaded from a server at fetch time.

The relevant section of the guide for launchd questions is the ​startupitem section, but MacPorts doesn't give you a lot of control over what goes into the plist; I see you're using StartInterval here which I don't think MacPorts knows about. In that case, you can install the plist manually like you're doing. Surprisingly, MacPorts doesn't check whether startupitem.create is yes when using the sudo port load and sudo port unload commands, so that works to your advantage in this case. Just make sure a symlink to the plist exists in /Library/LaunchDaemons/org.macports.${startupitem.name}.plist like you're doing.

[petrrr]

Replying to ryandesign@…:

The distfiles line should be deleted since the default will work fine. The plist shouldn't be listed there because it's going to be in the files directory, not downloaded from a server at fetch time.

Right, this was a left-over. Already deleted.

The relevant section of the guide for launchd questions is the ​startupitem section, but MacPorts doesn't give you a lot of control over what goes into the plist; I see you're using StartInterval here which I don't think MacPorts knows about. In that case, you can install the plist manually like you're doing. Surprisingly, MacPorts doesn't check whether startupitem.create is yes when using the sudo port load and sudo port unload commands, so that works to your advantage in this case. Just make sure a symlink to the plist exists in /Library/LaunchDaemons/org.macports.${startupitem.name}.plist like you're doing.

I renamed the plist file comply with the Macports naming scheme, but I realise it is not always followed by other ports.

lrwxr-xr-x   1 root  couchdb    57 Sep  4 18:01 org.apache.couchdb.plist -> /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist
lrwxr-xr-x   1 root  admin      63 Nov 23 21:45 org.freedesktop.avahi-daemon.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi-daemon.plist
lrwxr-xr-x   1 root  admin      65 Nov 23 21:45 org.freedesktop.avahi-dnsconfd.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi-dnsconfd.plist
lrwxr-xr-x   1 root  admin      66 Jul  4 16:58 org.freedesktop.dbus-system.plist -> /opt/local/Library/LaunchDaemons/org.freedesktop.dbus-system.plist
lrwxr-xr-x   1 root  admin      82 Aug 14 22:11 org.macports.VirtualBox.plist -> /opt/local/etc/LaunchDaemons/org.macports.VirtualBox/org.macports.VirtualBox.plist
lrwxr-xr-x   1 root  admin      76 Nov 12 17:06 org.macports.antinat.plist -> /opt/local/etc/LaunchDaemons/org.macports.antinat/org.macports.antinat.plist
lrwxr-xr-x   1 root  admin      76 Nov 20 19:12 org.macports.apache2.plist -> /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist
lrwxr-xr-x   1 root  admin      80 Mar 23  2013 org.macports.cassandra.plist -> /opt/local/etc/LaunchDaemons/org.macports.cassandra/org.macports.cassandra.plist
lrwxr-xr-x   1 root  admin      76 Nov  7 13:06 org.macports.mongodb.plist -> /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist
-rw-r--r--   1 root  admin     645 Sep 19 18:35 org.macports.privileged_startx.plist
lrwxr-xr-x   1 root  admin      74 Nov 18  2012 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist

So what is the background here, and why org.macports.privileged_startx.plist installed directly? Another doubt is about these subdirectories in

/opt/local/etc/LaunchDaemons:

petr% ls -la
total 8
drwxr-xr-x  10 root  admin   340 Nov 26 15:36 .
drwxr-xr-x  51 root  admin  1734 Nov 26 15:36 ..
-rwxr-xr-x   1 root  admin   453 Nov 23 21:45 org.freedesktop.avahi-daemon.plist
-rwxr-xr-x   1 root  admin   457 Nov 23 21:45 org.freedesktop.avahi-dnsconfd.plist
drwxr-xr-x   4 root  wheel   136 Aug 14 22:11 org.macports.VirtualBox
drwxr-xr-x   3 root  wheel   102 Nov 12 17:06 org.macports.antinat
drwxr-xr-x   4 root  wheel   136 Nov 22 22:32 org.macports.apache2
drwxr-xr-x   3 root  wheel   102 Nov  7 12:13 org.macports.cassandra
drwxr-xr-x   3 root  wheel   102 Nov  7 13:07 org.macports.mongodb
drwxr-xr-x   4 root  wheel   136 Oct 23 17:31 org.macports.rsyncd

I would have installed directly in /opt/local/etc/LaunchDaemons. Is there anything wrong about this?

The guide does not mention sudo port load and sudo port unload, but from port(1) I would understand that it translates to the corresponding launchctl commands. But the line

  system "launchctl remove org.eugridpma.fetch-crl || true"

has no correspondence. Is it save to just leave this line away? Is there some more magic involved with port load / unload?

Might it be possible and/or reasonable to use startupitem.create yes instead and add the StartInterval in a later stage? Is there some hook, e.g. something like startupitem-append to do this? Or at which stage this could be done?

Thanks!

[petrrr]

Okay this is where I got so far. I update the Portfile and attach org.macports.fetch-crl.plist​, which would go into files. The file org.eugridpma.fetch-crl.plist​ becomes irrelevant.

I still have some doubt on plist file handling, but see comment:7 for details.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Peter.Danecek@…:

I renamed the plist file comply with the Macports naming scheme, but I realise it is not always followed by other ports.

lrwxr-xr-x   1 root  couchdb    57 Sep  4 18:01 org.apache.couchdb.plist -> /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist
lrwxr-xr-x   1 root  admin      63 Nov 23 21:45 org.freedesktop.avahi-daemon.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi-daemon.plist
lrwxr-xr-x   1 root  admin      65 Nov 23 21:45 org.freedesktop.avahi-dnsconfd.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi-dnsconfd.plist
lrwxr-xr-x   1 root  admin      66 Jul  4 16:58 org.freedesktop.dbus-system.plist -> /opt/local/Library/LaunchDaemons/org.freedesktop.dbus-system.plist
lrwxr-xr-x   1 root  admin      82 Aug 14 22:11 org.macports.VirtualBox.plist -> /opt/local/etc/LaunchDaemons/org.macports.VirtualBox/org.macports.VirtualBox.plist
lrwxr-xr-x   1 root  admin      76 Nov 12 17:06 org.macports.antinat.plist -> /opt/local/etc/LaunchDaemons/org.macports.antinat/org.macports.antinat.plist
lrwxr-xr-x   1 root  admin      76 Nov 20 19:12 org.macports.apache2.plist -> /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist
lrwxr-xr-x   1 root  admin      80 Mar 23  2013 org.macports.cassandra.plist -> /opt/local/etc/LaunchDaemons/org.macports.cassandra/org.macports.cassandra.plist
lrwxr-xr-x   1 root  admin      76 Nov  7 13:06 org.macports.mongodb.plist -> /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist
-rw-r--r--   1 root  admin     645 Sep 19 18:35 org.macports.privileged_startx.plist
lrwxr-xr-x   1 root  admin      74 Nov 18  2012 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist

And this has been a problem, for example you'll find many tickets (e.g. #34359) and mailing list discussions from people encountering errors on activation of dbus, because its plist has a nonstandard name. Launchd plists have to be installed in (or symlinked into) the public directory /Library/LaunchDaemons, so if a user wants to ​uninstall MacPorts but the port command is not working and he has to resort to using sudo rm -rf, the best we can do is give them a list of globs patterns to delete, and since /Library/LaunchDaemons may contain non-MacPorts files, we can't tell them to delete everything there; we can only tell them to delete everything starting with org.macports, which doesn't cover ports like dbus that install plists with different prefixes, so the dbus files remain. Then the user reinstalls MacPorts and encounters errors activating dbus. So if you're installing a launchd plist with MacPorts, please if possible use the org.macports prefix.

So what is the background here, and why org.macports.privileged_startx.plist installed directly?

I suppose because the xinit port is a little unusual. You could ask that port's maintainer why it's done that way. It may be a bug. It may be part of the cause for ​this problem. Best would be to do what MacPorts base does: install in ${prefix}/etc/LaunchDaemons, then, if requested, symlink to the real location.

Another doubt is about these subdirectories in

/opt/local/etc/LaunchDaemons:

petr% ls -la
total 8
drwxr-xr-x  10 root  admin   340 Nov 26 15:36 .
drwxr-xr-x  51 root  admin  1734 Nov 26 15:36 ..
-rwxr-xr-x   1 root  admin   453 Nov 23 21:45 org.freedesktop.avahi-daemon.plist
-rwxr-xr-x   1 root  admin   457 Nov 23 21:45 org.freedesktop.avahi-dnsconfd.plist
drwxr-xr-x   4 root  wheel   136 Aug 14 22:11 org.macports.VirtualBox
drwxr-xr-x   3 root  wheel   102 Nov 12 17:06 org.macports.antinat
drwxr-xr-x   4 root  wheel   136 Nov 22 22:32 org.macports.apache2
drwxr-xr-x   3 root  wheel   102 Nov  7 12:13 org.macports.cassandra
drwxr-xr-x   3 root  wheel   102 Nov  7 13:07 org.macports.mongodb
drwxr-xr-x   4 root  wheel   136 Oct 23 17:31 org.macports.rsyncd

I would have installed directly in /opt/local/etc/LaunchDaemons. Is there anything wrong about this?

It looks like MacPorts base creates directories when the port specifies startupitem.start, startupitem.stop, and/or startupitem.restart, because in those cases it needs to write a short wrapper shell script containing those commands and references that script from the plist, and I guess it seemed neater to have only a single item in ${prefix}/etc/LaunchDaemons for each port. When using startupitem.executable instead, which is the preferred method, then the plist can reference that executable directly and doesn't need a wrapper script.

The guide does not mention sudo port load and sudo port unload, but from port(1) I would understand that it translates to the corresponding launchctl commands. But the line

  system "launchctl remove org.eugridpma.fetch-crl || true"

has no correspondence. Is it save to just leave this line away? Is there some more magic involved with port load / unload?

There's no magic; port load and port unload map directly to launchctl; e.g. browser:trunk/base/src/port1.0/portload.tcl​. From this we can also see that the path you should be symlinking the plist to is /Library/${startupitem.location}/${startupitem.plist}.

I don't know what launchctl remove does.

Might it be possible and/or reasonable to use startupitem.create yes instead and add the StartInterval in a later stage? Is there some hook, e.g. something like startupitem-append to do this? Or at which stage this could be done?

There's no hook specifically for that. This is what I meant when I said above that MacPorts doesn't give you a lot of control over it. I don't know exactly when the plist is created; you could try patching it in post-destroot if you want to go that route.

[petrrr]

I am reconsidering the function of this port slightly.

Actually this port makes the assumption that certificates go (will go) into ${prefix}/etc/grid-security/certificates. This might not be the case and above all depends on choices made elsewhere (e.g. igtf-bundle see ticket #41532). On the other hand, the utilities provided by this port, are potentially useful in a context independent of any prepackages certificate bundle, for example if the user decides to manage certificates manually or to install them in /etc/grid-security for example, this tools still could be used.

So this is what I propose:

• this port installs only the utilities, the docu and an example config file;
• does no default configuration and no launchd magic;
• such configuration is moved to any potential user (dependent) of this port, e.g. (future) igtf-bundle port;
• igtf-bundle will depend on this port and use it to make a first request for CRLs on activation, and clean CRLs when deactivated; It may provide a auto-fetch launchd service as well;

[petrrr]

I did some testing and share here some findings.

Replying to ryandesign@…:

I don't know what launchctl remove does.

Seems, that this does basically the same as unload but does not require a plist file, instead it uses the job label.

Might it be possible and/or reasonable to use startupitem.create yes instead and add the StartInterval in a later stage? Is there some hook, e.g. something like startupitem-append to do this? Or at which stage this could be done?

There's no hook specifically for that. This is what I meant when I said above that MacPorts doesn't give you a lot of control over it. I don't know exactly when the plist is created; you could try patching it in post-destroot if you want to go that route.

I conclude, there is now no way to patch/modify/replace the created plist file. The reason is that the plist is created and added in the destroot-stage, but the files and links are not yet in place when post-destroot is executed. So the startupitem related stuff (and the message) are created after after post-destroot. Not sure if this is the best way to handle startupitem.

[petrrr]

new version of the Portfile, updated to @3.0.13

[petrrr]

the plist file to go into files directory

[petrrr]

I updated the Portfile and it now provides to ports:

• fetch-crl installs only the utility
• fetch-crl-launchd installs the launchd entry
• The port is now bumped to @3.0.13

I think, the problems from the former discussion are solved.

Please review and commit, Thanks!

[skymoo (Adam Mercer)]

Thanks, I'm swamped at the moment, with deadlines at work and visitors in town, but should be able to take a look at this after 3rd June. Hopefully someone else with commit access can get to it sooner...

[petrrr]

Laters small change related to corresponding change to #41532.

The cached state files are now purged on deactivate here.

[petrrr]

small corrected

[petrrr]

A small correction to the ui_msg statements, according to ticket:41532#comment:27.

[petrrr]

Replying to ram@…:

Thanks, I'm swamped at the moment, with deadlines at work and visitors in town, but should be able to take a look at this after 3rd June. Hopefully someone else with commit access can get to it sooner...

Hi, could you have a look at this now?

[petrrr]

updated Portfile

[petrrr]

I just updated the Portfile for fetch-crl: version bump and maintainer address changed.

You will find the whole port here as well. I would appreciate if someone could audit it before I commit. It works fine for me, but maybe someone with more experienced might have a different idea on how it should be solved. Thanks!

[skymoo (Adam Mercer)]

Sorry for the delay, but this looks good to me.

[petrrr]

Thanks! So I'll commit this and move on the tricky parts.

[petrrr]

Committed in r121398.