change .conf files' ownership from root wheel to root admin

[Chris Jones]

Migrations like this should just follow the recommendations as per the 
migration guide.

https://trac.macports.org/wiki/Migration

On 10/04/2019 4:01 pm, Gabriel Rosenkoetter wrote:
> On 2019-04-09 12:59 EDT, Murray Eisenberg wrote:
>> I migrated my apps, docs, library from an old Mac to a new one, both
>> using macOS Mojave 10.14.4.
> 
> What command did you use for this "migration"? It sounds like you
> executed it as root (or under sudo(1)), but did not tell it to preserve
> ownership (and maybe not even permissions).
> 
> That'll probably cause you significantly more problems down the line
> than just not being able to edit specific config files.
> 
>> On the old Mac, many MacPorts .conf files were owned by user root, group
>> admin. Those include httpd.conf, httpd-vhosts.conf, httpd-userdir.conf
> 
> Is the old Mac still around? If so, you could repeat the process but
> make sure you tell whatever program you use to perserve permissions.
> There are lots of tools to do this, here are just a few commonly-used
> examples:
> 
> tar(1) via ssh:
>    tar c srcdir [[srcdir]…] | ssh <newmac> ( cd / && tar xp[v] )
> 
> pax(1) can also be used via ssh, but let's pretend that you've got both
> file systems visible on the same system (eg, via SMB) for this example:
> 
>    pax -rw -pe [-v] srcdir [[srcdir]…] /Volumes/newmac
> 
> rsync(1) is good if you expect to want to resynchronize things later
> (which may not be important here), and it's also pretty smart about file
> handling:
> 
>    rysnc -avzR --no-implied-dirs srcdir [[srcdir]…] [newmac:]/dest
> 
>> On the new Mac, these files are now owned by user root, but group wheel.
>> That means I cannot edit these .conf files under my user account, which
>> is in the admin group.
>>
>> How can I fix this so as to restore these files to group admin instead
>> of wheel?
> 
> One thing you *can* do is use find(1) to locate all files now owned by
> root:wheel and -exec chgrp admin on them, but I don't think that's a
> good idea, given the situation you described. I think that this symptom
> indicates that there's probably way more files that have the wrong
> permissions for them, and I think you should probably try the copy
> again, preserving permissions.
>