Bug 187659

Summary: mail/spamassassin: undesireable change in startup
Product: Ports & Packages Reporter: Lawrence Chen <beastie>
Component: Individual Port(s)Assignee: Adam Weinberger <adamw>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Lawrence Chen 2014-03-17 13:20:00 UTC
	
	spamd is now creating user preferences files, ignoring my wishes.

Fix: 

From spamd(1):

	    -c, --create-prefs
	      Create user preferences files if they don't exist (default: don't).

	What's wrong with the default?

	Because in 3.4.0_5, the '-c' switch was moved from "spamd_flags" to
	"command_args" overriding that my "spamd_flags" intentionally does not
	contain this switch.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2014-03-17 13:20:04 UTC
Responsible Changed
From-To: freebsd-ports-bugs->adamw

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 adamw 2014-03-17 13:35:55 UTC
The problem is that before I was getting complaints that the provided 
instructions were failing because the user preference files WEREN'T 
being created when people changed spamd_flags.

I do see your point though... now it's much more difficult to remove the 
-c than it was for others to add it.

In the meantime you can remove the -c from /usr/local/etc/rc.d/sa-spamd.

I'm not 100% on how to solve the problem for everybody. Suggestions, 
Lawrence?

# Adam
Comment 3 Adam Weinberger freebsd_committer freebsd_triage 2014-03-17 13:36:21 UTC
State Changed
From-To: open->analyzed
Comment 4 Lawrence Chen 2014-03-17 15:39:56 UTC
Perhaps the provided instructions should include what the default was, and/or
include "-c" in the suggested change?  Though I do run spamassassin with 
something like "-u spamd -H /var/spool/spamd ..." and I'm fine that it 
doesn't create a user_prefs (that sets nothing).

OTOH, many years ago we once decided that a new lower score threshold was 
more effective, but not wanting to interfere with existing users we used this 
to create initial user_prefs so new users get this new default.

Our home directory quota policy is still from the stone age... its 8 MB.  
And, that's the max for students, graduate students can ask to have it 
increased to 16 MB and faculty/staff to 32 MB.  And, if you knew the right 
person it can be more ;)


On 2014-03-17 08:35, Adam Weinberger wrote:
> The problem is that before I was getting complaints that the provided
> instructions were failing because the user preference files WEREN'T being
> created when people changed spamd_flags.
> 
> I do see your point though... now it's much more difficult to remove the -c
> than it was for others to add it.
> 
> In the meantime you can remove the -c from /usr/local/etc/rc.d/sa-spamd.
> 
> I'm not 100% on how to solve the problem for everybody. Suggestions, 
> Lawrence?
> 
> # Adam

-- 
   Name: Lawrence "The Dreamer" Chen    Call: W0LKC
  Snail: 1530 College Ave, A5          Email: beastie@tardisi.com
         Manhattan, KS 66502-2768       Blog: http://lawrencechen.net
Comment 5 dfilter service freebsd_committer freebsd_triage 2014-04-01 15:07:01 UTC
Author: adamw
Date: Tue Apr  1 14:06:57 2014
New Revision: 349854
URL: http://svnweb.freebsd.org/changeset/ports/349854
QAT: https://qat.redports.org/buildarchive/r349854/

Log:
  Partially revert r348415. There are many good scenarios where
  preventing user-config file creation is a good thing. Recommend
  one of those scenarios in the rc.d description.
  
  PR:		ports/187659
  Submitted by:	Lawrence "The Dreamer" Chen <beastie@tardisi.com>

Modified:
  head/japanese/spamassassin/Makefile
  head/mail/spamassassin/Makefile
  head/mail/spamassassin/files/sa-spamd.in

Modified: head/japanese/spamassassin/Makefile
==============================================================================
--- head/japanese/spamassassin/Makefile	Tue Apr  1 13:17:18 2014	(r349853)
+++ head/japanese/spamassassin/Makefile	Tue Apr  1 14:06:57 2014	(r349854)
@@ -1,7 +1,7 @@
 # Created by: TAOKA Fumiyoshi
 # $FreeBSD$
 
-PORTREVISION=	7
+PORTREVISION=	8
 CATEGORIES=	japanese mail perl5
 PKGNAMEPREFIX=	ja-
 

Modified: head/mail/spamassassin/Makefile
==============================================================================
--- head/mail/spamassassin/Makefile	Tue Apr  1 13:17:18 2014	(r349853)
+++ head/mail/spamassassin/Makefile	Tue Apr  1 14:06:57 2014	(r349854)
@@ -3,7 +3,7 @@
 
 PORTNAME=		spamassassin
 PORTVERSION=	3.4.0
-PORTREVISION?=	7		# also bump japanese/spamassassin
+PORTREVISION?=	8		# also bump japanese/spamassassin
 CATEGORIES?=	mail perl5
 MASTER_SITES=	${MASTER_SITE_APACHE:S/$/:apache/} ${MASTER_SITE_PERL_CPAN:S/$/:cpan/}
 MASTER_SITE_SUBDIR=	spamassassin/source/:apache Mail/:cpan

Modified: head/mail/spamassassin/files/sa-spamd.in
==============================================================================
--- head/mail/spamassassin/files/sa-spamd.in	Tue Apr  1 13:17:18 2014	(r349853)
+++ head/mail/spamassassin/files/sa-spamd.in	Tue Apr  1 14:06:57 2014	(r349854)
@@ -22,6 +22,8 @@
 #
 #	 spamd_flags="-Q"
 #
+# and remove -c (auto-create user preference files).
+#
 
 . /etc/rc.subr
 
@@ -33,11 +35,11 @@ load_rc_config $name
 
 # Set defaults
 : ${spamd_enable:="NO"}
-: ${spamd_flags="%%SQL_FLAG%% %%RUN_AS_USER%%"}
+: ${spamd_flags="-c %%SQL_FLAG%% %%RUN_AS_USER%%"}
 
 pidfile=${spamd_pidfile:-"/var/run/${name}/${name}.pid"}
 command=%%PREFIX%%/bin/${name}
-command_args="-c -d -r ${pidfile}"
+command_args="-d -r ${pidfile}"
 required_dirs=%%PREFIX%%/share/spamassassin
 
 run_rc_command "$1"
_______________________________________________
svn-ports-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-ports-all
To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org"
Comment 6 Adam Weinberger freebsd_committer freebsd_triage 2014-04-01 15:07:11 UTC
State Changed
From-To: analyzed->closed

After some meditation, I realized that you are completely right. 
I mean, the whole point of keeping user config files in SQL is 
to avoid creating dotfiles in each user's homedir, right? 

I've put -c back in the overridable flags, where it was before. 
Thanks for this PR, Lawrence, and for being patient while it 
took me a long time to resolve this PR.