Greg!
Well, I got lucky.
Most of the links created on my base image were originally created =20
with earlier versions of the Radmind tools. When doing "find / -perm =20
700 -type l -exec ls -l {} ';'" on my PPC image I didn't actually =20
find any affected symlinks. When I did it on the Universal image (the =20=
one I'm having the problem with) I found about 25 or so. I update =20
base images on a very infrequent basis since they do a Radmind update =20=
on first boot. Probably thanks to this I found that my _base_ =20
universal image also had no bad symlinks. Therefore, fixing the =20
Radmind update script in my base image was sufficient to my situation.
YMMV.
Come to think of it, this might be the best way to find targets to =20
fix for the "fix" script too...
Sam
On 19 Apr 2007, at 18:34, Neagle, Greg wrote:
> You're probably correct, but I'm not certain how that would fix =20
> existing symlinks that currently have the wrong permissions.
>
> -Greg
>
> On Apr 18, 2007, at 9:56 PM, Sam Agnew wrote:
>
>> Greg!
>>
>> Wow! I hope I didn't cause you too much extra effort. I had a =20
>> colleague here try to cook up a k-in-k version. Someone with a =20
>> little more Perl chops than me. It seemed to work but seemed to =20
>> remove all the links before trying to fetch new ones. Since this =20
>> involved most of the system libraries it broke the OS before =20
>> completing.
>>
>> I took a different tack.
>>
>> I simply added "-u 022" to the lapply section of my Radmind update =20=
>> script and made this change on my base disk image. It is my =20
>> understanding that this perm mask will ONLY be used for file =20
>> system objects which don't have explicit permissions set in the =20
>> transcript. True? If true then I think this will be my solution to =20=
>> the problem here.
>>
>> Sam
>>
>> --
>> Sam Agnew
>> Unix System Administrator
>> IT Department
>> Weill Cornell Medical College in Qatar
>>
>>
>> On 18 Apr 2007, at 20:44, Neagle, Greg wrote:
>>
>>> Nope, I don't. Didn't need it for myself. Here's an untested =20
>>> version...
>>>
>>> -Greg
>>>
>>> #!/usr/bin/perl -w
>>>
>>> # fixSymlinks.pl
>>> # by Greg Neagle, greg.neagle@...
>>>
>>> # - This script attempts to fix broken symlinks created by lapply =20=
>>> 1.5.1
>>> # when run with the default umask option
>>> #
>>> # - No attempt is made to fix symlinks referenced in negative =20
>>> transcripts
>>> #
>>> # - Symlinks that are referenced in a positive transcript and a
>>> # higher-precedence negative transcript therefore _will_ be =20
>>> modified,
>>> # this could be bad. In my loadsets, I can find no actual =20
>>> occurrences
>>> # of this problem, since the only symlink I have in any negative =20
>>> transcript
>>> # is this one:
>>> # l /private/etc/localtime /usr/share/zoneinfo/US/=20
>>> Pacific
>>> # and it doesn't appear in any other transcripts. But the danger =20=
>>> is there.
>>> #
>>> # - A deeper potential problem is transcript entries that =20
>>> _remove_ symlinks:
>>> # if a transcript creates a symlink, and a higher-precedence =20
>>> transcript
>>> # removes it, we'll have an unwanted symlink hanging around. A =20
>>> subsequent
>>> # radmind session will remove it, but if this script is run =20
>>> again, it will
>>> # come back.
>>> #
>>> # - Therefore we need to deal with "- l" lines in the transcripts =20=
>>> as well.
>>> # Unfortunately, we cannot just blindly pass these lines to =20
>>> lapply, because if
>>> # symlink doesn't exist in the filesystem, lapply will fail and =20
>>> stop processing
>>> # transcript lines.
>>> #
>>> # So we'll need to feed symlink removal lines to lapply one-by-=20
>>> one and ignore
>>> # failures.
>>>
>>> use strict;
>>>
>>> my $radmindClientDir =3D "/var/radmind/client";
>>> my $commandFile =3D "command.K";
>>> my $symlinkremovet =3D "/tmp/symlinkremove.T";
>>>
>>> #turn off output buffering
>>> $|++;
>>>
>>> chdir $radmindClientDir;
>>> process($commandFile);
>>> exit 0;
>>>
>>> sub process {
>>> my $localCommandFile =3D $_[0];
>>> (open K, $localCommandFile) or die "Can't open the command =
file!";
>>> while (<K>) {
>>> my $commandFileLine =3D $_;
>>> if ($commandFileLine =3D~ /^k/) {
>>> #handle nested command files
>>> my @lineItems =3D split;
>>> my $nestedCommandFile =3D $lineItems[1];
>>> print "Processing =
$nestedCommandFile...\n";
>>> process($nestedCommandFile);
>>> }
>>> if ($commandFileLine =3D~ /^p/) {
>>> #positive transcript
>>> my @lineItems =3D split;
>>> my $transcript =3D =
$lineItems[1];
>>> print "\tProcessing =
$transcript...\n";
>>> # re-create all symlinks in the =
transcript:
>>> # grep out all lines that begin =
with l and send them
>>> # to lapply with a 022 umask
>>> system "/usr/bin/grep -h \"^l\" =
\"$radmindClientDir/=20
>>> $transcript\" | /usr/local/bin/lapply -u 022";
>>> # grab symlink removal lines
>>> system "/usr/bin/grep -h \"^- =
l\" \"$radmindClientDir/=20
>>> $transcript\" > $symlinkremovet";
>>> print "Removing symlinks flagged =
for removal in =20
>>> $transcript...\n";
>>> if (open T, $symlinkremovet) {
>>> while (<T>) {
>>> =
#feed each line one-by-one to lapply
>>> =
chomp;
>>> =
system "echo $_ | /usr/local/bin/lapply -u 022";
>>> }
>>> close T;
>>> }
>>> }
>>> }
>>> close K;
>>> }
>>>
>>>
>>> On Apr 17, 2007, at 11:43 PM, Sam Agnew wrote:
>>>
>>>> Greg!
>>>>
>>>> Sorry to come so late to the party, so to speak. Have you got an =20=
>>>> updated version of this which deals with nested KinK situations? =20=
>>>> Turns out I need this.
>>>>
>>>> Sam
>>>>
>>>> --
>>>> Sam Agnew
>>>> Unix System Administrator
>>>> IT Department
>>>> Weill Cornell Medical College in Qatar
>>>>
>>>>
>>>> On 3 Mar 2006, at 01:53, Neagle, Greg wrote:
>>>>
>>>>> Here's a script that should fix all the wacky symlinks on your =20
>>>>> system(s). It's had only basic testing, but I think it's OK.
>>>>>
>>>>> #!/usr/bin/perl =96w
>>>>>
>>>>> # fixSymlinks.pl
>>>>> # by Greg Neagle, greg.neagle@...
>>>>>
>>>>> # - This script attempts to fix broken symlinks created by =20
>>>>> lapply 1.5.1
>>>>> # when run with the default umask option
>>>>> #
>>>>> # - No attempt is made to fix symlinks referenced in negative =20
>>>>> transcripts
>>>>> #
>>>>> # - Symlinks that are referenced in a positive transcript and a
>>>>> # higher-precedence negative transcript therefore _will_ be =20
>>>>> modified,
>>>>> # this could be bad. In my loadsets, I can find no actual =20
>>>>> occurrences
>>>>> # of this problem, since the only symlink I have in any =20
>>>>> negative transcript
>>>>> # is this one:
>>>>> # l /private/etc/localtime /usr/share/zoneinfo/=20
>>>>> US/Pacific
>>>>> # and it doesn't appear in any other transcripts. But the =20
>>>>> danger is there.
>>>>> #
>>>>> # - A deeper potential problem is transcript entries that =20
>>>>> _remove_ symlinks:
>>>>> # if a transcript creates a symlink, and a higher-precedence =20
>>>>> transcript
>>>>> # removes it, we'll have an unwanted symlink hanging around. A =20=
>>>>> subsequent
>>>>> # radmind session will remove it, but if this script is run =20
>>>>> again, it will
>>>>> # come back.
>>>>> #
>>>>> # - Therefore we need to deal with "- l" lines in the =20
>>>>> transcripts as well.
>>>>> # Unfortunately, we cannot just blindly pass these lines to =20
>>>>> lapply, because if
>>>>> # symlink doesn't exist in the filesystem, lapply will fail and =20=
>>>>> stop processing
>>>>> # transcript lines.
>>>>> #
>>>>> # So we'll need to feed symlink removal lines to lapply one-by-=20
>>>>> one and ignore
>>>>> # failures.
>>>>>
>>>>> use strict;
>>>>>
>>>>> my $radmindClientDir =3D "/var/radmind/client";
>>>>> my $commandFile =3D $radmindClientDir . "/command.K";
>>>>> my $symlinkremovet =3D "/tmp/symlinkremove.T";
>>>>>
>>>>> #turn off output buffering
>>>>> $|++;
>>>>>
>>>>> (open K, $commandFile) or die "Can't open the command file!";
>>>>> while (<K>) {
>>>>> my $commandFileLine =3D $_;
>>>>> if ($commandFileLine =3D~ /^p/) {
>>>>> #positive transcript
>>>>> my @lineItems =3D split;
>>>>> my $transcript =3D $lineItems[1];
>>>>> print "Processing $transcript...\n";
>>>>> # re-create all symlinks in the transcript:
>>>>> # grep out all lines that begin with l and send them
>>>>> # to lapply with a 022 umask
>>>>> system "/usr/bin/grep -h \"^l\" \"$radmindClientDir/=20
>>>>> $transcript\" | /usr/local/bin/lapply -u 022";
>>>>> # grab symlink removal lines
>>>>> system "/usr/bin/grep -h \"^- l\" \"$radmindClientDir/=20
>>>>> $transcript\" > $symlinkremovet";
>>>>> print "Removing symlinks flagged for removal in =20
>>>>> $transcript...\n";
>>>>> if (open T, $symlinkremovet) {
>>>>> while (<T>) {
>>>>> #feed each line one-by-one to lapply
>>>>> chomp;
>>>>> system "echo $_ | /usr/local/bin/lapply -u 022";
>>>>> }
>>>>> close T;
>>>>> }
>>>>> }
>>>>> }
>>>>> close K;
>>>>>
>>>>>
>>>>> On 3/2/06 11:42 AM, "Neagle, Greg" <Greg.Neagle@...> wrote:
>>>>>
>>>>> > I just filed Apple Bug ID# 4464550 : Incorrect symlink =20
>>>>> behavior in Tiger
>>>>> >
>>>>> > Summary:
>>>>> > Tiger incorrectly pays attention to permissions on symlinks.
>>>>> >
>>>>> > Steps to reproduce:
>>>>> > (istanbul.fas) root [210] % uname -a
>>>>> > Darwin istanbul.fas.fa.disney.com 8.5.0 Darwin Kernel Version =20=
>>>>> 8.5.0: Sun Jan
>>>>> > 22 10:38:46 PST 2006; root:xnu-792.6.61.obj~1/RELEASE_PPC =20
>>>>> Power Macintosh
>>>>> > powerpc
>>>>> > (istanbul.fas) root [211] % cd /
>>>>> > (istanbul.fas) root [212] % umask 077
>>>>> > (istanbul.fas) root [213] % ln -s /Users/Shared /Shared
>>>>> > (istanbul.fas) root [214] % ls -al /Shared
>>>>> > lrwx------ 1 root admin 13 Mar 2 10:33 /Shared@ -> /=20
>>>>> Users/Shared
>>>>> > (istanbul.fas) root [215] % umask 022
>>>>> > (istanbul.fas) root [216] % readlink /Shared
>>>>> > /Shared
>>>>> > (istanbul.fas) root [217] % exit
>>>>> > exit
>>>>> > (istanbul.fas) gneagle [202] % readlink /Shared
>>>>> >
>>>>> > Note that as root, "readlink /Shared" returns the target path:
>>>>> > "/Users/Shared".
>>>>> > As "gneagle", a non-privileged user, it returns nothing.
>>>>> >
>>>>> > Expected results:
>>>>> > For comparison, a similar sequence under Linux:
>>>>> >
>>>>> > (halibut) root [201] % uname -a
>>>>> > Linux halibut 2.6.9-27.EL.fa1smp #1 SMP Tue Jan 10 16:23:47 =20
>>>>> PST 2006 i686
>>>>> > i686 i386 GNU/Linux
>>>>> > (halibut) root [202] % pwd
>>>>> > /home/fahome/gneagle
>>>>> > (halibut) root [203] % umask 077
>>>>> > (halibut) root [204] % ln -s Documents/scripts scripts
>>>>> > (halibut) root [205] % ls -al scripts
>>>>> > lrwxrwxrwx 1 root root 17 Mar 2 10:42 scripts -> Documents/=20
>>>>> scripts/
>>>>> > (halibut) root [206] % readlink scripts
>>>>> > Documents/scripts
>>>>> > (halibut) root [207] % exit
>>>>> > exit
>>>>> > (halibut) gneagle [203] % readlink scripts
>>>>> > Documents/scripts
>>>>> >
>>>>> > Note that umask has no effect on mode for symlink creation, =20
>>>>> and that
>>>>> > readlink works for both root and gneagle.
>>>>> >
>>>>> > Actual results:
>>>>> > Some system calls respect the ownership and mode of symlinks.
>>>>> >
>>>>> > Regression:
>>>>> > Not tested. First saw this issue in 10.4.3, still occurs in =20
>>>>> 10.4.5. There
>>>>> > is no readlink command in Panther, so cannot test this =20
>>>>> directly, but other
>>>>> > tests indicate this issue does not exist in 10.3.9.
>>>>> >
>>>>> > Notes:
>>>>> > This issue was surfaced when using radmind (http://=20
>>>>> ww.radmind.org) to make
>>>>> > file system modifications - radmind runs as root and sets its =20=
>>>>> umask to 077
>>>>> > when creating files. This affects symlink creation, which =20
>>>>> then causes a
>>>>> > host of other problems.
>>>>> >
>>>>> > On 3/2/06 11:22 AM, "Wesley Craig" <wes@...> wrote:
>>>>> >
>>>>> >> Not at all. =46rom the shell:
>>>>> >>
>>>>> >> : Garden-State-wes:; ls -l foo
>>>>> >> ls: foo: No such file or directory
>>>>> >> : Garden-State-wes:; umask 077
>>>>> >> : Garden-State-wes:; ln -s bar foo
>>>>> >> : Garden-State-wes:; ls -lL foo
>>>>> >> lrwx------ 1 wes wes 3 Mar 2 14:20 foo -> bar
>>>>> >> : Garden-State-wes:;
>>>>> >>
>>>>> >> That's how to get a funky link. I suspect you know better =20
>>>>> than I how
>>>>> >> to demonstrate that the link doesn't work properly.
>>>>> >>
>>>>> >> :wes
>>>>> >>
>>>>> >> On 02 Mar 2006, at 12:46, James Reynolds wrote:
>>>>> >>> I'd file a bug, but I don't know the best way to explain =20
>>>>> how to
>>>>> >>> replicate the bug (I didn't exactly want to tell them to =20
>>>>> download
>>>>> >>> the radmind tools, make a transcript, etc...)? Can someone =20=
>>>>> tell me
>>>>> >>> the easiest way to reproduce this bug? I assume it =20
>>>>> involves some c
>>>>> >>> code.
>>>>> >>
>>>>> >>
>>>>> >> -------------------------------------------------------
>>>>> >> This SF.Net email is sponsored by xPML, a groundbreaking =20
>>>>> scripting language
>>>>> >> that extends applications into web and mobile media. Attend =20
>>>>> the live webcast
>>>>> >> and join the prime developer group breaking into this new =20
>>>>> coding territory!
>>>>> >> http://sel.as-us.falkag.net/sel?=20
>>>>> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>>>> >> _______________________________________________
>>>>> >> Radmind-users mailing list
>>>>> >> Radmind-users@...
>>>>> >> https://lists.sourceforge.net/lists/listinfo/radmind-users
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > -------------------------------------------------------
>>>>> > This SF.Net email is sponsored by xPML, a groundbreaking =20
>>>>> scripting language
>>>>> > that extends applications into web and mobile media. Attend =20
>>>>> the live webcast
>>>>> > and join the prime developer group breaking into this new =20
>>>>> coding territory!
>>>>> > http://sel.as-us.falkag.net/sel?=20
>>>>> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>>>> > _______________________________________________
>>>>> > Radmind-users mailing list
>>>>> > Radmind-users@...
>>>>> > https://lists.sourceforge.net/lists/listinfo/radmind-users
>>>>
>>>
>>
>> ---------------------------------------------------------------------=20=
>> ----
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/=20
>> _______________________________________________
>> Radmind-users mailing list
>> Radmind-users@...
>> https://lists.sourceforge.net/lists/listinfo/radmind-users
>
---
Sam Agnew
Unix System Administrator
Weill Cornell Medical College in Qatar
|