After updating dcc-dccd from version 1.3.158 to 1.3.159 I get the following error in maillog:
Jun 20 08:49:46 mx dccproc: open(/usr/local/dcc/map): Permission denied
% ls -l /usr/local/dcc/map
-rw------- 1 dcc wheel 7700 Jun 20 08:51 /usr/local/dcc/map
% ls -l /usr/local/dcc/map
-rw------- 1 root wheel 7700 Jun 20 08:53 /usr/local/dcc/map
Other files with different owner:
It seems to be an upstream error. I don't use DCC as a daemon, so I haven't noticed. Patch will follow shortly with $CHOWN's in Makefile, which will hopefully restore the previous behavior.
Created attachment 183759 [details]
It seems like ownership set in Makefile is properly set in the relevant files in $STAGEDIR, but pkg-install.in sets them again to root:wheel. The patch sets ownsership in pkg-install. Could you try the port now?
In maillog, I now get:
Jun 24 12:14:56 FreeBSD10 dccifd: 1.3.159 listening to /usr/local/dcc/dccifd for ASCII protocol
(In reply to Piotr Kubaj from comment #2)
I'm glad you responded with a solution! I have been spending a bit too much time on this issue.
Patch looks good, but it will need a revision bump, Thanks!
Created attachment 183829 [details]
Corrected patch with PORTREVISION bump.
(In reply to Piotr Kubaj from comment #4)
Would it be possible to change the extension and not edit the .sample file, something like
`map.nopasswd.sample` <--- this is the only one of these in the pkg-plist and not modified.
The problem as stated in the message correctly is that it will break the pkg checksum data. If instead of using the sample copy, use as a template it will prevent such checksum breakage and equivalents for the other two files.
There are other ports that do similar procedures but they aren't really the same as with sample config files, and we shouldn't try and mash the two into one mechanism.
Created attachment 183911 [details]
Did you mean something like this? It doesn't make pkg show any checksum warnings, but I'm quite sure the nopasswd files are not going to be read by DCC. Since each user needs a unique password, it's quite understandable that the files are going to be different across installs.
(In reply to Piotr Kubaj from comment #6)
Yes, but you are correct they wouldn't be read. The .sample would need to be copied to .nopasswd. Also this is just an example, this extension doesn't need to be the chosen one to use.
Do you know if the port uses the .sample hardcoded? or in a config? Hopefully the extension used is set by the script fix-map.
One other query, what are your thoughts on adding this step to the RC script instead of using post-install?
> It seems to be an upstream error.
that is mistaken. It is an error introduced after I submitted the patch for bug #216799
Please see my comments in bug #216799
> I don't use DCC as a daemon, so I haven't noticed. Patch will follow shortly with $CHOWN's in Makefile, which will hopefully restore the previous behavior.
Instead of adding a chown to the Makefile, wouldn't it be better to fix the pkt_plist file including the last 3 lines?
The .sample files are FreeBSD inventions that I know nothing about. The DCC Makefiles create create map, ids, and other files.
The map file is a binary snapshot of DCC server information including round trip times, client-IDs, and passwords used by DCC clients including dccifd, dccm, and dccproc. As such, it changes constantly. An initial, default maps file is built by the DCC Makefiles.
A map.txt file is generated and loaded into the new map file by the DCC Makefiles when there is no existing map file. Thereafter map.txt is merely the output of the command cdcc info.
The ids file is used by the cdcc command to get server passwords and by dccd. It is not changed by DCC programs other than by the DCC Makefiles creating a new file. Every installed ids file is likely to be unique because of the generated password that it contains. Users with DCC servers must change it. An initial default ids file is also created by the DCC Makefiles.
Fiddling with configuration files in RC scripts sounds undesirable and fragile to me.
Please note that realsoonnow I'll be releasing version 1.3.160.
I'd just like to point out that, as mentioned in bug 216799, the ownership of /usr/local/dcc/ itself is set to root:wheel preventing dccproc from writing new files to the directory.
This was creating an additional error:
dccproc: lock_open(/usr/local/dcc/whiteclnt.dccx): Permission denied; file not writeable for locking
Created attachment 184018 [details]
After testing these changes supplied by Piotr Kubaj everything appears to be set correctly. This patch is the fixed from the previous one with the last couple of lines @owner and @group removed from the pkg-plist to set the correct DCCHOME directory user/group.
(In reply to Richard Gallamore from comment #10)
After email@example.com's explanation. it looks ok.
A commit references this bug:
Date: Mon Jul 3 17:37:56 UTC 2017
New revision: 444972
* Fix permissions from regression on r443717
Submitted by: Piotr Kubaj <firstname.lastname@example.org> (maintainer)
Reviewed by: lifanov (mentor), matthew (mentor)
Approved by: lifanov (mentor)
Differential Revision: https://reviews.freebsd.org/D11347