From: peter pilsl on

I just moved a bunch of files from one system to another using tar/gzip.
Now after unpacking and modifying I realized that on a small number of
files the group-ownership is wrong (some strange bug in tar/gzip I guess
cause this didnt happen the first time).

So now I just want to sync (probably with rsync) the group-ownerships,
*but not the filecontent itself*, cause some of the files have already
been altered on the new system and shall not be overwritten !!

How can I do this?

thnx
peter
From: Walter Mautner on
peter pilsl wrote:

>
> I just moved a bunch of files from one system to another using tar/gzip.
> Now after unpacking and modifying I realized that on a small number of
> files the group-ownership is wrong (some strange bug in tar/gzip I guess
> cause this didnt happen the first time).
>
Groups are represented by simple numbers. When you do a "ls -l" followed by
a "ls -ln" you'll get a clue.
The translation table from number to the names showed is /etc/group.
Another system may well have another /etc/group.
A analogy exists with SSIDs/RIDs in windows world.

> So now I just want to sync (probably with rsync) the group-ownerships,
> *but not the filecontent itself*, cause some of the files have already
> been altered on the new system and shall not be overwritten !!
>
> How can I do this?
>
For bigger *nix farms, there is usually central authentication/user/group
replication from a nis+ or ldap server.
In the windows world, that would be a domain server.

--
vista policy violation: Microsoft optical mouse found penguin patterns
on mousepad. Partition scan in progress to remove offending
incompatible products. Reactivate MS software.
Linux 2.6.24. [LinuxCounter#295241,ICQ#4918962]
From: peter pilsl on


>>
> Groups are represented by simple numbers. When you do a "ls -l" followed by
> a "ls -ln" you'll get a clue.
> The translation table from number to the names showed is /etc/group.
> Another system may well have another /etc/group.
> A analogy exists with SSIDs/RIDs in windows world.
>

Ok. Sorry I didnt put my questions clear in the first place.

My problem is:

After tar and retar some gids are wrong.

On the source-system the gid of a certain file was 101 and on the
target-system its now 102. This happenend for a unknown number of
files/directories. I've discoverered 4 such problems till now.

I'm looking for a way to set the gids on the targetsystem according to
the source-system without transferring/updating the files itself (the
content) cause its a huge number of files, a slow networkconnection and
the files on the targetsystems already have been alterers.

/etc/passwd and /etc/groups are same on both systems and no
nis/radius-server is in place.

There was a problem with gid when transferring the files and I need a
cheap way to fix it.

thnx
peter

From: Walter Mautner on
peter pilsl wrote:

>
>
>>>
>> Groups are represented by simple numbers. When you do a "ls -l" followed
>> by a "ls -ln" you'll get a clue.
>> The translation table from number to the names showed is /etc/group.
>> Another system may well have another /etc/group.
>> A analogy exists with SSIDs/RIDs in windows world.
>>
>
> Ok. Sorry I didnt put my questions clear in the first place.
>
> My problem is:
>
> After tar and retar some gids are wrong.
>
> On the source-system the gid of a certain file was 101 and on the
> target-system its now 102. This happenend for a unknown number of
> files/directories. I've discoverered 4 such problems till now.
>
That sounds a bit crazy. Like - after repacking on the clone - some damned
script did "reconfigure" the user setup.
Of course, that problem should stay limited to a few places. Watching
logfiles while starting affected services, and chmod'ing erranous groups
will probably still be the fastest workaround.
But then, when you unpack the archive in a safe place and watch the output
of ls -ln for affected folders/files, without booting first - what do you
see?

> There was a problem with gid when transferring the files and I need a
> cheap way to fix it.
>
No real cheapie. I remember once makine a script that recursively (on the
source side) grabs acls (getfacl ....) to intermediate *.acl files,
transferring these files over to the corresponding filestructure on the
target machine, then reapplying the acls (setfacl ...) there.
--
vista policy violation: Microsoft optical mouse found penguin patterns
on mousepad. Partition scan in progress to remove offending
incompatible products. Reactivate MS software.
Linux 2.6.24. [LinuxCounter#295241,ICQ#4918962]
From: Dave B on
peter pilsl wrote:

> My problem is:
>
> After tar and retar some gids are wrong.
>
> On the source-system the gid of a certain file was 101 and on the
> target-system its now 102. This happenend for a unknown number of
> files/directories. I've discoverered 4 such problems till now.
>
> I'm looking for a way to set the gids on the targetsystem according to
> the source-system without transferring/updating the files itself (the
> content) cause its a huge number of files, a slow networkconnection and
> the files on the targetsystems already have been alterers.

At your own risk: you could generate a script (on the source system) that
chowns the files with the appropriate owners, something eg like (on the
source system)

find /src/dir -type f -printf "chown %U:%G '%p'\n" > script.sh

(assuming /src/dir is what you tarred in the first place)

Then, on the target system, run script.sh in the directory where you
unpacked the tarball. Make sure that you understand what script.sh does, and
double / triple check that the filenames inside it make sense on the target
system in the directory from which you run it (which, as I said, should be
the one where you unpacked the tarball).

Also please note that the script assumes that your files do not have single
quotes in their names (other funny characters should be ok though).

--
D.