logwatch 7.3.6, new port

[lassi.tuura@…]

I have attached a port file for security/logwatch, a log file analysis tool.

[snc@…]

Lassi: You might consider letting macports create the launchd item as the install path is not necessarily /opt/local.

[snc@…]

Cc Me!

[lassi.tuura@…]

Thanks. By "letting macports create" do you mean there's some standard mechanism to spit out launchd items, or I should just sed the install path in the Portfile to match $prefix? If the former, could you please point me to the documentation or an example, as I think I have missed it...

[snc@…]

Yes, there's an actual mechanism built-in that you can base your efforts from. Check out ​http://guide.macports.org/#reference.startupitems

[lassi.tuura@…]

Thanks! I had looked at that documentation, but wasn't able to work out how to create a cron-style job instead of a daemon, and was hesitant to whack at port-generated start-up item so much. Can you suggest a concrete example I could look at? If there's no direct support for cron-style, which do you feel is more obvious and maintainable, using the existing infrastructure to produce basic plist then edit it with plutil / defaults, or the current template adjusted to account for $prefix etc.?

[snc@…]

It seems cron-style launchd items are not yet implemented in MacPorts. Looking at #16969, it might be on the way in the future.

That being said, I'd suggest that you have the launchd item created in your portfile dynamically (or do a find/replace from macports on the one supplied to fill in the paths). Making sure the path are correct is fairly important part of macport's functionality.

For ideas on how to write the files, I previously generated other kinds of scripts found at the bottom of: ​http://trac.macports.org/changeset/45332/trunk/dports/math/pspp/Portfile

Let me know if you need some more ideas.

[lassi.tuura@…]

OK, I'll remodel the port file so it writes the launchd item rather than taking a stock file.

[lassi.tuura@…]

I updated port file to generate launchd plist dynamically rather than taking a static file.

[snc@…]

since i had suggested looking at pspp, i was informed that these should be included in ./files

[snc@…]

updated for the included launchd file

[snc@…]

added ui_msg to inform user of launchd startup script

[snc@…]

The latest portfile and included script builds and installs for me.

If everything is the way you'd like it I'm ready to commit these.

[lassi.tuura@…]

Thanks, yes, am happy with it as it is. I've been running it for months now, and did test before submitting the update that it did produce the desired result. (Well, I fudged the time it runs, waited for the time to pass, inspected the report it mailed, then restored the time back to night time.)

[snc@…]

Committed as r46644.

[lassi.tuura@…]

Sorry, I hadn't noticed some of the changes to the port file you had added -- when you said the "latest" I hadn't noticed the changes made by you, as I didn't receive any e-mail notification and didn't read the web page carefully enough. My apologies.

The "ui_msg" lines refer to "dnsmasq", should this not be "logwatch"? There is also a missing "h" in "launcd". Both are on line 58. (Thanks for adding the message, I was wondering how to make one and under which circumstances.)

I also noticed the plist now runs the command directly rather than via /bin/sh. I am not sure this will work as for me logwatch needed /opt/local/bin in $PATH. Does logwatch run for you via launchd without setting $PATH? I wonder if I have some anti-dependency on my system.

[snc@…]

Replying to lassi.tuura@…:

The "ui_msg" lines refer to "dnsmasq", should this not be "logwatch"? There is also a missing "h" in "launcd". Both are on line 58. (Thanks for adding the message, I was wondering how to make one and under which circumstances.)

You're absolutely correct. I was mimicking dnsmasq's ui_msg too closely!

I also noticed the plist now runs the command directly rather than via /bin/sh. I am not sure this will work as for me logwatch needed /opt/local/bin in $PATH. Does logwatch run for you via launchd without setting $PATH? I wonder if I have some anti-dependency on my system.

I've never had an issue with running the binaries directly from launchd. You'll notice that the binary is run with it's full path to avoid the issue you likely had. Launchd confirms the event is loaded (sudo launchctl list | less logwatch) and will sit waiting for the designated time to occur.

I did notice that, upon running the binary directly (sudo logwatch) there was an error: /opt/local/var/cache/logwatch No such file or directory at /opt/local/bin/logwatch line 751. It seems we need to create that directory.

I'll attach a couple patches shortly showing how I intend to fix these issues. If they're satisfactory I'll apply them.

[snc@…]

ui_msg changes, destroot.keepdirs added, bumped revision. builds and runs successfully for me.

[lassi.tuura@…]

I think some confusion on my part here, sorry. The script creates ${destroot}${prefix}/var/cache/${name} and even the undesirable ".turd" file. Did the directory really not exist for you after installing logwatch?

I previously had some problem not with running logwatch itself, but something it wanted to execute internally. I am unable to replicate it right now; it appears to work fine without setting $PATH, and I do not recall the problem I originally had. Let's leave it as it is, without $PATH.

I will upload shortly my updated port file, trying to account for your changes plus the other requests: move reinplace to build, don't create .turd file, and don't touch /Library in destroot step. I also attached a diff, but it's not against svn, it's just against your Portfile.4.

[lassi.tuura@…]

Combined merge of previous diff plus requested changes from macports admins.

[snc@…]

Replying to lassi.tuura@…:

I think some confusion on my part here, sorry. The script creates ${destroot}${prefix}/var/cache/${name} and even the undesirable ".turd" file. Did the directory really not exist for you after installing logwatch?

The portfile does create the ${destroot}${prefix}/var/cache/{$name} but it doesn't install it. The destroot.keepdirs parameter forces it to install that directory. That was the only error I had come across running logwatch.

[lassi.tuura@…]

Cumulative patch.

[snc@…]

Committed as r46695. If there are new issues, I suggest a new ticket: All original issues have been addressed.

[anonymous]

Milestone Port Submissions deleted