|
Prev: How to remove specific file extensions recursively in subdirectories?
Next: How to remove specific file extensions recursively insubdirectories?
From: peter pilsl on 22 Jun 2008 18:10 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 23 Jun 2008 03:01 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 23 Jun 2008 06:03 >> > 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 23 Jun 2008 09:45 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 23 Jun 2008 12:09
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. |