packages vs sources (was: Cron command?)
2015-04-21 19:47 GMT+03:00 Mark Sapiro <mark@msapiro.net>:
This is a packager thing (RHEL/CentOS ?). Mailman as distributed by the GNU Mailman project does not do this (never did). Our docs are <http://www.list.org/mailman-install/node41.html> and recommend installing our crontab as a user crontab with the crontab command.
...
The bottom line is that it's best, as always, to install a component such as a crontab using the supplied tools rather trying to second-guess the tool set and copying files directly.
+1
Many people rely on their distribution packagers - is this bad?
I always prefer to use yum/apt-get instead of compiling software from source. The reasons are obvious (all they are in any package system mission statement).
Mailman is one of the few exception of this rule on my servers because of importance of its new versions and rare packages updates. :( (It's shame that they include 2.1.15 in the new Centos7 distribution!)
But if we 'use supplied tools' and lost distribution integration - like removing cron entries automatically when 'service mailman stop' - does this make sense at all?
Danil
On 04/21/2015 10:37 AM, Danil Smirnov wrote:
Many people rely on their distribution packagers - is this bad?
I always prefer to use yum/apt-get instead of compiling software from source. The reasons are obvious (all they are in any package system mission statement).
Mailman is one of the few exception of this rule on my servers because of importance of its new versions and rare packages updates. :( (It's shame that they include 2.1.15 in the new Centos7 distribution!)
You have answered your own question.
But if we 'use supplied tools' and lost distribution integration - like removing cron entries automatically when 'service mailman stop' - does this make sense at all?
The OP (and I) were only referring to using the 'crontab' command to install/edit a crontab rather than directly copying/editing files.
In the case of a package which installs/removes Mailman's crontab as part of it's init.d script, this translates to "if you want to edit Mailman's crontab, edit the source file, not the /etc/cron.d/mailman file. And, in this case, it is incumbent on the packager to make this clear in the package documentation.
But this raises the question, if you are installing Mailman from source, why do you still have artifacts from the distro's package still in your installation.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
2015-04-21 21:23 GMT+03:00 Mark Sapiro <mark@msapiro.net>:
But this raises the question, if you are installing Mailman from source, why do you still have artifacts from the distro's package still in your installation.
Why you name them 'artefacts'? I consider them very convenient technology working great for Mailman 2.1.18-1 also. I can stop and start Mailman service with 'service' tool and I don't need to worry about crontab entries.
Give me a reason why I wouldn't do this.
Danil
On 04/21/2015 12:18 PM, Danil Smirnov wrote:
2015-04-21 21:23 GMT+03:00 Mark Sapiro <mark@msapiro.net>:
But this raises the question, if you are installing Mailman from source, why do you still have artifacts from the distro's package still in your installation.
Why you name them 'artefacts'? I consider them very convenient technology working great for Mailman 2.1.18-1 also. I can stop and start Mailman service with 'service' tool and I don't need to worry about crontab entries.
They are things that are in some sense left over from a prior install of a distro's Mailman package. Had you just installed Mailman from source without ever installing the package, you would not be aware of them. Thus, they are artifacts left over from the package.
Give me a reason why I wouldn't do this.
If you know exactly what you are doing and how things that remain from the package interact with your source install/upgrade, that's fine, and if you like those specific things you continue to use, there's no reason not to.
But those conditions don't apply to everyone and people sometimes get themselves in trouble when they knowingly or unknowingly mix things from a package with things from the source distribution that may not be compatible in the ways that they do things.
For example, your packages /etc/init.d/mailman script copies (apparently) /opt/local/share/mailman/cron/crontab.in or maybe /(var|usr)/lib/mailman/cron/crontab.in to /etc/cron.d/mailman.
If in the process of installing/upgrading your installation from the source distribution you had copied the source cron/crontab.in to whatever crontab.in the /etc/init.d/mailman script copies from, it would not work because the source cron/crontab.in is a 'user' crontab and doesn't have 'mailman' as the 6th field in the entries.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
2015-04-21 23:10 GMT+03:00 Mark Sapiro <mark@msapiro.net>:
They are things that are in some sense left over from a prior install of a distro's Mailman package. Had you just installed Mailman from source without ever installing the package, you would not be aware of them. Thus, they are artifacts left over from the package.
Using 'service' scripts to control ALL server's services (Mailman IS a service irrespective of its version, right?) isn't absurd or non-sense. I think one should respect distribution structure and keep things work as distribution creator's intended.
Considering this 'packagers related' stuff as not important and insisting on 'native' way to use cron has less sense for me than the opposite. Why standard control of Mailman service in very popular distribution family has no reflection in Mailman documentation you mentioned and sometimes considers like 'artefacts'?
May be this attitude has some influence on that fact that there is so old version of Mailman in last Centos release?...
Danil
On 04/21/2015 01:38 PM, Danil Smirnov wrote:
Using 'service' scripts to control ALL server's services (Mailman IS a service irrespective of its version, right?) isn't absurd or non-sense. I think one should respect distribution structure and keep things work as distribution creator's intended.
Mailman is not a service on your server if you don't install it either from source or a package. Your /etc/init.d/mailmnan script was installed by your Mailman package. It wasn't there before you installed the package.
The source distribution also includes an init.d script at scripts/mailman and instructions for installing it are in comments at its beginning and in the installation manual at <http://www.list.org/mailman-install/node42.html>, so you can see, we definitely support 'service' scripts.
Considering this 'packagers related' stuff as not important and insisting on 'native' way to use cron has less sense for me than the opposite. Why standard control of Mailman service in very popular distribution family has no reflection in Mailman documentation you mentioned and sometimes considers like 'artefacts'?
See the above. The only thing I'm calling 'packagers related' is the specific content of the init.d script, not the concept.
May be this attitude has some influence on that fact that there is so old version of Mailman in last Centos release?...
You would have to as Red Hat about that? I don't see what "attitude" you are talking about here that would affect the version that Red Hat and hence CentOS chooses to include in a particular distro.
Do we have a communication disconnect of some kind here?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
2015-04-22 0:05 GMT+03:00 Mark Sapiro <mark@msapiro.net>:
The source distribution also includes an init.d script at scripts/mailman and instructions for installing it are in comments at its beginning and in the installation manual at <http://www.list.org/mailman-install/node42.html>, so you can see, we definitely support 'service' scripts.
Is it also support cron entries to remove them when stopping? This is the main topic of the discussion.
You described cron entries copying procedure as 'artifacts' - if init.d script supports fully the same functionality, I must agree that 'packager stuff' are really artifacts...
Do we have a communication disconnect of some kind here?
Perhaps. :)
Danil
On 4/21/2015 1:38 PM, Danil Smirnov wrote:
Using 'service' scripts to control ALL server's services [...] Considering this 'packagers related' stuff as not important and insisting on 'native' way to use cron has less sense for me than the opposite. Why standard control of Mailman service in very popular distribution family has no reflection in Mailman documentation you mentioned and sometimes considers like 'artefacts'?
What 'service' scripts?
On 4/21/2015 2:17 PM, Danil Smirnov wrote:
You described cron entries copying procedure as 'artifacts' - if init.d script supports fully the same functionality, I must agree that 'packager stuff' are really artifacts...
See, here's the thing- my systems don't have /etc/init.d/; I put the mailman startup in /etc/rc.local. (I use some very popular bsd distros, which are rather different from other *nix distros, which are rather different from other other *nix distros. It's a lot of work to keep track of all of them.) If the MM doc needs to be updated, I'm sure the offer would be well-received.
z!
On 04/21/2015 02:17 PM, Danil Smirnov wrote:
You described cron entries copying procedure as 'artifacts'
Yes, I described the specific content of your init.d/mailman script as an artifact[1] if your package.
Do we have a communication disconnect of some kind here?
Perhaps. :)
I use the word 'artifact in the sense of definition 6 at <http://dictionary.reference.com/browse/artifact>, i.e. "any feature that is not naturally present but is a product of an extrinsic agent, method, or the like:". In this case, some content that would not be there if you had never installed the package, but had installed from source following the procedures in our manual at <http://www.list.org/mailman-install/index.html>. Thus, that content is an artifact of your package install.
Clearly this word means something pejorative to you, but I had no such intent.
Whether it is preferable to install Mailman's crontab as a user or system crontab is a matter of taste. Whether it is appropriate to disable Mailman's cron jobs when mailman is not running is arguable. If it works for you, fine, but it seems to me that you would only want to do this on a production server if you decided to shut Mailman down entirely and permanently. If mailman was only going to be stopped for a short period for some reason, would you really want to not run the checkdbs, disabled, senddigests or mailpasswds cron jobs just because their time was in that window. Maybe that would be the case for you, but it is not a decision the I would feel comfortable making for all installations that use Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Carl Zwanzig -
Danil Smirnov -
Mark Sapiro