As reported in bug 7674, a number of changes are needed, to allow the inn service to start, including permission and path changes. I'll add more details shortly.
Created attachment 2977 [details] Output of "inncheck -f -perm".
The script innshellvars is in /usr/bin, but ... grep -I /usr/lib64/inn/news /usr/bin/* 2>/dev/null /usr/bin/actmerge:. /usr/lib64/inn/news/innshellvars /usr/bin/actsyncd:. /usr/lib64/inn/news/innshellvars /usr/bin/controlbatch:. /usr/lib64/inn/news/innshellvars /usr/bin/docheckgroups:. /usr/lib64/inn/news/innshellvars /usr/bin/expirerm:. /usr/lib64/inn/news/innshellvars /usr/bin/innstat:. /usr/lib64/inn/news/innshellvars /usr/bin/innwatch:. /usr/lib64/inn/news/innshellvars /usr/bin/news.daily:. /usr/lib64/inn/news/innshellvars /usr/bin/nntpsend:. /usr/lib64/inn/news/innshellvars /usr/bin/scanlogs:. /usr/lib64/inn/news/innshellvars /usr/bin/send-ihave:. /usr/lib64/inn/news/innshellvars /usr/bin/send-nntp:. /usr/lib64/inn/news/innshellvars /usr/bin/sendxbatches:. /usr/lib64/inn/news/innshellvars /usr/bin/tally.control:. /usr/lib64/inn/news/innshellvars /usr/bin/writelog:. /usr/lib64/inn/news/innshellvars For testing of bug 7674, I've used ... # mkdir -p /usr/lib64/inn/news # ln -s /usr/bin/innshellvars /usr/lib64/inn/news/ Probably better to fix the scripts in /usr/bin/listed above.
To fix the problems shown by inncheck, I've used # ln -s /etc/rc.news /usr/bin/ # inncheck -f -perm | /bin/sh I've also deleted the line [ -d /usr/lib/news ] || exit 0 from /etc/init.d/innd, as the directory does not exist on a 64 bit install.
Oden, is this change you made in Cauldron correct? - --with-berkeleydb=/usr/include/db4 \ + --with-berkeleydb=%{_prefix} \
CC: (none) => luigiwalserAssignee: bugsquad => oe
It makes no difference as neither finds a suitable ndbm.h. I don't know when that worked, 5-10 years ago?
Probably, it's in libdb1-devel, so that would be pretty old. I wonder if it's buildable against gdbm, since it has that header too.
Probably, but the point is that this is a non issue as db support hasn't been there for many years.
@Dave, thanks for all your testing on this package. I have taken most of your findings and have now created a new inn-2.5.3-2.mga2 package. This one should hopefully start out of the box!
CC: (none) => remcoAssignee: oe => qa-bugs
Version: Cauldron => 2
Thanks. Finally got around to testing this. Everything looks good, without running inncheck, but if people are used to running it ... # inncheck -f -perm|sort -u chgrp news /usr/bin chgrp news /usr/bin/inews chgrp news /usr/lib64 chgrp news /usr/tmp chmod 550 /usr/bin/inews chmod 775 /usr/tmp chown news /etc/news/incoming.conf chown news /usr/bin chown news /usr/bin/inews chown news /usr/lib64 chown news /usr/tmp As it is, it will make many things rw, for the news daemon, that shouldn't be. In my opinion, the script should be removed, changed into a no-op, or modified not to try and make the above modifications.
Whiteboard: (none) => feedback
Also notice the inncheck script reports # /usr/bin/rc.news:0: missing. rc.news is in /etc, not /usr/bin.
Assigning Remco. Could you please take a look at Dave's comments above. Please re-assign to QA when you're ready. Thanks!
CC: (none) => qa-bugsAssignee: qa-bugs => remco
Sorry to piggyback on this mga2 bug, but Remco, just in case you missed it on IRC, another issue with this package in Cauldron: there's a conflict between inn and leafnode, as they have /var/spool/news with 775 and 755 perms, respectively. They should be the same, or the packages should explicitly conflict. The permissions should probably be 755 unless there's a good reason otherwise.
Sorry for the long delay. Version inn-2.5.3-3.2.mga2 is available in updates_testing now. It addresses the issue David raised in comment #12. Dave's findings under comment #9 does not impact the functionality of the program, and half of them seem to be incorrect (like changing ownership of /usr/bin). For comment #10, I believe the inncheck script to actually be in error. Can we stamp an approval on this one please so those who want to run inn at least can run it using an official Mageia package? :-)
Assignee: remco => qa-bugs
Oops feedback tag was left on, sorry.
Whiteboard: feedback => (none)
Advisory 7876.adv uploaded to svn
Testing complete on Mageia 2 i586 and x86_64 using procdure attachment 2979 [details] Could someone from the sysadmin team push 7876.adv to updates.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA2-64-OK MGA2-32-OKCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2013-0069.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED