Radmind

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 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 modified,
# this could be bad.  In my loadsets, I can find no actual 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/Pacific
# and it doesn't appear in any other transcripts.  But the danger is =20
there.
#
# - A deeper potential problem is transcript entries that _remove_ =20
symlinks:
# if a transcript creates a symlink, and a higher-precedence 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 again, it =20=

will
# come back.
#
# - Therefore we need to deal with "- l" lines in the transcripts as =20
well.
# Unfortunately, we cannot just blindly pass these lines to lapply, =20
because if
# symlink doesn't exist in the filesystem, lapply will fail and stop =20
processing
# transcript lines.
#
# So we'll need to feed symlink removal lines to lapply one-by-one =20
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/$transcript=20
\" | /usr/local/bin/lapply -u 022";
					# grab symlink removal lines
					system "/usr/bin/grep -h \"^- =
l\" \"$radmindClientDir/$transcript=20
\" > $symlinkremovet";
					print "Removing symlinks flagged =
for removal in $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 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 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 _remove_ =20=

>> 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 again, =20=

>> 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-one =20=

>> 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 behavior =20
>> 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 Power =20
>> 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@ -> /Users/=20
>> 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 PST =20
>> 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, and =20
>> 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 directly, =20=

>> 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 then =20=

>> 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 than =20=

>> 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 how to
>> >>> replicate the bug (I didn't exactly want to tell them to download
>> >>> the radmind tools, make a transcript, etc...)?  Can someone =20
>> tell me
>> >>> the easiest way to reproduce this bug?  I assume it involves =20
>> 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 the =20=

>> 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 the =20
>> live webcast
>> > and join the prime developer group breaking into this new coding =20=

>> 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
>

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 little =20=

more Perl chops than me. It seemed to work but seemed to remove all =20
the links before trying to fetch new ones. Since this involved most =20
of the system libraries it broke the OS before 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 system =20
objects which don't have explicit permissions set in the transcript. =20
True? If true then I think this will be my solution to 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 modified,
> # this could be bad.  In my loadsets, I can find no actual 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 _remove_ =20
> 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 again, =20
> 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 lapply, =20=

> 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-one =20
> 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/$transcript=20
> \" | /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 $transcript...=20
> \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 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 $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 behavior =20=

>>> 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 Power =20=

>>> 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@ -> /Users/=20
>>> 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 PST =20=

>>> 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, and =20=

>>> 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 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 involves =20
>>> 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 the =20=

>>> 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
>>
>

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

On 10 Apr 2007, at 09:49, Jeremy Reichman wrote:
> If encryption were then optional for the payload --
> and granted, I'm only wishing/hoping this is possible -- the client  
> session
> overhead would be reduced.

An unencrypted session is easy to hijack.

> Turning off encryption on our local network links (i.e. use -w0,  
> which means
> we use our DDNS hostnames for client identification) _and_ disabling
> checksums during daytime runs only allowed low-end Power Mac G4s to  
> complete
> a Radmind run in ~10 minutes rather than more than 45, for example.  
> The
> improvement is less dramatic, but still noticeable, on hardware  
> that is
> newer than seven years old. ;) Also, I would expect that most of the
> overhead was caused by -csha1.

Yeah, the difference between checksums and no checksums is enormous.   
After all, without checksums, fsdiff doesn't read the content of the  
files on the disk.  Even a "low end" G4 has amble CPU available for  
encrypting the ktcheck & lapply streams.  As a general rule, even  
without checksums enabled, a radmind update has a disk IO  
bottleneck.  Thus, until your CPU usage becomes so large that it is  
instead the bottleneck, it will have virtually no impact on real time  
to completion.

:wes

On 4/10/07 11:54 AM, "Wesley Craig" <wes@...> wrote:

> On 10 Apr 2007, at 09:49, Jeremy Reichman wrote:
>> If encryption were then optional for the payload --
>> and granted, I'm only wishing/hoping this is possible -- the client
>> session
>> overhead would be reduced.
> 
> An unencrypted session is easy to hijack.

I'll take your word for it. However, my point is that some of us who might
be interested in arbitrary text might be doing so to avoid some of the
overhead of full-session encryption inherent with certificate usage. There
might be a case for only wanting to use certificates simply for client
and/or server verification, as an alternative for arbitrary strings.

However, I'm not in the market for arbitrary strings for identification. It
simply wouldn't work for me -- but I've also got working dynamic DNS, too,
so either that or certificates covers most of my use cases.

>> Turning off encryption on our local network links (i.e. use -w0,
>> which means
>> we use our DDNS hostnames for client identification) _and_ disabling
>> checksums during daytime runs only allowed low-end Power Mac G4s to
>> complete
>> a Radmind run in ~10 minutes rather than more than 45, for example.
>> The
>> improvement is less dramatic, but still noticeable, on hardware
>> that is
>> newer than seven years old. ;) Also, I would expect that most of the
>> overhead was caused by -csha1.
> 
> Yeah, the difference between checksums and no checksums is enormous.
> After all, without checksums, fsdiff doesn't read the content of the
> files on the disk.  Even a "low end" G4 has amble CPU available for
> encrypting the ktcheck & lapply streams.  As a general rule, even
> without checksums enabled, a radmind update has a disk IO
> bottleneck.  Thus, until your CPU usage becomes so large that it is
> instead the bottleneck, it will have virtually no impact on real time
> to completion.

Continuing off-topic: I agree that fsdiff's disk I/O seems to be the most
likely bottleneck on these older systems I manage, especially with
checksums. The single and dual G4s both run about the same speed for their
Radmind sessions, and their CPU usage is not terribly high. The computers,
though, virtually grind to a halt during a Radmind run, probably due to this
contention.

They all have single hard disks of the same capacity and vintage, and are of
course connected to ATA-5/6 busses of the same rough performance level.

Anecdotally, a loaner 24-in iMac I Radminded completed faster than either a
Core Duo iMac or a MacBook Pro Core 2 Duo -- while I haven't benchmarked the
disks, there's likely a difference in the 3.5-in vs. 2.5-in mechanisms at
work there.


-- 
Jeremy Reichman
Senior Desktop Systems Engineer
Information and Technology Services
Rochester Institute of Technology

On 10 Apr 2007, at 15:17, Jeremy Reichman wrote:
> There
> might be a case for only wanting to use certificates simply for client
> and/or server verification, as an alternative for arbitrary strings.

You know, thinking about it for a minute, SSL can run with very  
little or no encryption.  Radmind isn't instrumented to allow it, but  
there are API calls that allow a program to indicate which crypto is  
available.  If you were to only make the "null" crypto available,  
then I guess that would be what you're suggesting.  And I'm not  
endorsing this approach :)

> Anecdotally, a loaner 24-in iMac I Radminded completed faster than  
> either a
> Core Duo iMac or a MacBook Pro Core 2 Duo -- while I haven't  
> benchmarked the
> disks, there's likely a difference in the 3.5-in vs. 2.5-in  
> mechanisms at
> work there.

Disk rotational speed can make a big difference.  My 7200 RPM laptop  
drive runs circles (groan) around a similarly configured machine with  
a 5400 RPM drive.

:wes

FYI:

I have uploaded an article, "Automate ASR Image Creation Using  
Radmind & Script" to MacEnterprise web site.

To view article, see url...
http://macenterprise.org/content/view/300/77/

Hope you find it useful.

On 4/5/07 8:05 AM, "Will Maier" <willmaier@...> wrote:

> On Thu, Apr 05, 2007 at 08:38:49AM -0400, Jim Kirkum wrote:
>> 1)  Add machines to your radmind config prior to registering them
>> on your network - perfect if you know where the machines will be
>> going as they come into the warehouse, as they print the mac
>> address on the outside of the box.
>=20
> By adding the new machines to your DHCP server (which you'll
> probably want to do, anyway) and assigning specific addresses to
> specific MACs, you can achieve the same result. Just use the IP
> addresses in the config; you can then use radmind to pass out
> host-specific certs (as I do). Once the clients have their real
> certs installed, I then replace the IP addresses in the config with
> the client's CN.

That is so kludgy. Why not just use static IPS then? It's not a slick
solution.=20
=20
> (Also, few of the machines we buy and manage with radmind have the
> MAC address printed on the chassis, but one could just as easily
> discover the MACs using SNMP and a reasonable switch.)
>=20
>> 2)  Have another way that you could handle laptops or other roving
>> machines that might not always have a consistent IP address or DNS
>> name.
>=20
> This is exactly the use case that made me investigate ramdind.
> Unless you're talking about adding the MAC address to the RAP, I
> don't see how MAC support would help. MAC addresses aren't passed
> across networks by layer three devices, so unless your laptops are
> all roving on the same physical network, the radmind client would
> need to advertise the MAC at some point during the session with the
> server.
>=20
> Advertising the MAC during the session seems redundant and less
> useful than the certs that are already supported. Certs are more
> flexible: you can create any sort of CN that you want, which can
> become a very powerful option when combined with globs in the config
> file. At best, MAC addresses would allow you to sort or filter
> clients by the manufacturer of their NIC.
>=20
> I don't think adding support for MAC addresses would be a bad thing,
> but it seems like it wouldn't be terribly useful.













=20


=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95
Jim Lagnese
Technology Director
Apple Certified System Administrator
East Union Community Schools
1916 High School Drive
Afton, IA 50830
http://www.east-union.k12.ia.us
Office: 641-347-8421
Cell: 515-321-7301
email: jlagnese@...
AIM: macmanlag
iChat: jlagnese@...
yahoo: jdlagnese
MSN: macmanjim@...
=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95=95

Confidentiality Notice: =A0This email and any attachments may be covered by
the Electronic Communications Privacy Act, 18 U.S.C.=A7=A72510-2521 and may
contain privileged and confidential information intended only for the use o=
f
the individual or entity named. =A0If you are not the intended recipient, you
are hereby notified that you should not review, use, disclose, distribute,
copy, or forward this email. =A0If you have received this email in error,
please notify the sender immediately and delete/destroy any and all copies
of the original message.

20 apr 2007 kl. 18.23 skrev James Lagnese:

>> By adding the new machines to your DHCP server (which you'll
>> probably want to do, anyway) and assigning specific addresses to
>> specific MACs, you can achieve the same result. Just use the IP
>> addresses in the config; you can then use radmind to pass out
>> host-specific certs (as I do). Once the clients have their real
>> certs installed, I then replace the IP addresses in the config with
>> the client's CN.
>
> That is so kludgy. Why not just use static IPS then? It's not a slick
> solution.

I think I have a good reason: OD-LDAP info. Distributed via DHCP to  
clients makes it easy to change eg proxy or name servers (or anything  
else). With static IP you have to change this on each client. This is  
maybe not a big matter but if you have to change network settings it  
is easy to do it in an DHCP environment.

I put MAC addresses in my DHCP server and assign static IPs to  
clients. Then I put IP addresses on the radmind server. It works well  
but is a bit tedious.

A dream would be to have an interface in radmind like ARD with the  
ability to use smart groups. That would be something! I have my  
computers named by location and then by a number eg "0338 iMac- 
Nr095643". In ARD I make smart lists that groups all computers in  
location 0338 and so on. This is really good and easy. In radmind it  
would be nice if I could make smart list after computer type or  
location or other criteria. And then a network scan tool or some way  
to discover clients built in radmind server...

/Mats-Olof Liljegren

On Fri, Apr 20, 2007 at 11:23:57AM -0500, James Lagnese wrote:
> > By adding the new machines to your DHCP server (which you'll
> > probably want to do, anyway) and assigning specific addresses to
> > specific MACs, you can achieve the same result. Just use the IP
> > addresses in the config; you can then use radmind to pass out
> > host-specific certs (as I do). Once the clients have their real
> > certs installed, I then replace the IP addresses in the config
> > with the client's CN.
> 
> That is so kludgy. Why not just use static IPS then? It's not a
> slick solution. 

I don't see the kludge here. I've used DHCP on machines with fixed
addresses for a long time; it greatly simplifies management. In this
case, I find it especially beneficial, because I don't need to use
radmind to manage /etc/resolv.conf and the handful of other files
that dhclient takes care of.

-- 

[Will Maier]-----------------[willmaier@... href="http://www.lfod.us/" target="_new">http://www.lfod.us/]

On Apr 19, 2007, at 9:08 AM, Joseph Cheng wrote:

> Hello...I found this email post about using radmind with red hat
> especially tricking the rpm database so things like rpm -qa can still
> work on radmind maintained red hat
> servers....http://groups.google.ca/group/radmind-users/ 
> browse_thread/thread/da5d650743ed19ce/30538da3f3aa86e9? 
> lnk=st&q=radmind+with+rpm&rnum=2&hl=en#30538da3f3aa86e9
> Redhat experts please share your radmind recipes. What is a fail proof
> way of making rpm work while using radmind?

I don't have a lot of experience running radmind on RedHat, but I  
think there are two options:

1) Ignore the rpm database. Install things via rpm, use radmind to  
capture changes as loadsets, distribute to other clients via radmind.  
This works just fine, though without the rpm database you won't be  
able to type rpm commands to view installed packages.

2) Use "rpm --freshen --justdb PACKAGENAME" after running radmind  
updates, probably in a post-apply script. The easiest way to do this  
would be to make sure your loadsets have the same names as the rpms  
you're installing, e.g., "binutils-1.9.9-extra-junk.rpm" would be  
captured by radmind as "binutils-1.9.9-extra-junk.T", and your script  
could handle the name difference properly. You could also put  
comments in your transcripts indicating which rpms were represented:

# This transcript contains the following rpms:
# RPM: coreutils-1.x.x-yar.rpm
# RPM: findutils-2.y.y-avast.rpm
# RPM: yeti-20070104-ahoy.rpm
f ./etc/some/config.conf ...
f ./etc/some/other.conf ...
....

Then your post-apply script could look for the "# RPM" lines in your  
transcripts and run the rpm --freshen --justdb command against the  
given rpms.

> Also like original
> poster's request any sample red hat transcripts available online for
> the minimal install?

There's an old one from Chris Messina. You can find it here:

http://rsug.itd.umich.edu/software/radmind/linux.html

andrew
rsug

On Apr 11, 2007, at 12:07 PM, Sam Cornn wrote:

> I want to use RadmindAssistant 0.9.6 to update G3 "all in ones"  
> that are  running os x 10.2.8
> I get an error: dyld: /usr/local/bin/lcreate can't open library: / 
> usr/lib/libcrypto.0.9.7.dylib  (No such file or directory, errno = 2)

I believe the version of Radmind (1.5.0) included with RA 0.9.6 was  
built on 10.3, and expects certain libraries to be available to it  
that are not included with 10.2.8. You can use Radmind 1.5 with that  
version of the Assistant, but you will have to compile it and install  
it yourself. Instructions for compiling can be found here:

<http://sourceforge.net/docman/display_doc.php? 
docid=35498&group_id=141444>

Ignore the bits about getting the source from CVS. Download the  
Radmind source here:

<http://sourceforge.net/project/showfiles.php? 
group_id=141444&package_id=155276>

Alternatively, you can use an older precompiled version of Radmind,  
available on the same page as the source. If you choose this option,  
you may need to go back as far as Radmind 1.3.2.

andrew
rsug

On Apr 10, 2007, at 9:54 AM, Gary Bernstein wrote:

> Do you think it is safe to remove all of /var/tmp then?

Probably. This line:

mkdir -p -m 01777 /private/var/tmp /private/tmp

appears in /etc/rc, so if it is removed, it will get recreated on  
reboot.

>
> -Gary
> On Apr 10, 2007, at 8:14 AM, Andrew Mortensen wrote:
>
>>
>> On Apr 10, 2007, at 3:47 AM, Sam Agnew wrote:
>>
>>> My nightly Radmind script reboots at the end. Is /var/tmp not
>>> cleared on reboot? Hmm... Maybe only /tmp is cleared...
>>
>> Looks to me like Apple changed that. /var/tmp used to be removed and
>> recreated on reboot by /etc/rc. Now only "/var/tmp/folders.*" is
>> deleted. Filing a bug report is always an option.
>>
>> andrew
>>
>>>
>>> Sam
>>>
>>> On 9 Apr 2007, at 21:29, Quade Boman wrote:
>>>
>>>> I've also recently noticed the large amount of files located in /
>>>> private/var/tmp.  In our case, there is often large files that
>>>> ClamXav leaves behind, eating up hard drive space on older
>>>> machines.  I was going to add a cleaning routine to our nightly
>>>> scripts to remove the contents of this directory.
>>>>
>>>>
>>>>
>>>> radmind-users@... on Monday, April 9, 2007 at
>>>> 9:46 AM -0800 wrote:
>>>>
>>>> Message: 9
>>>> Date: Mon, 9 Apr 2007 11:46:33 -0500
>>>> From: Gary Bernstein <bernsteg@...>
>>>> Subject: [Radmind-users] /var/tmp
>>>> To: Radmind mailing list -- Radmind Users
>>>>         <radmind-users@...>
>>>> Message-ID: <5FF96C21-424B-492F-9690-84C99A216D8B@...>
>>>> Content-Type: text/plain; charset="us-ascii"
>>>>
>>>> Has anyone else noticed a growing number of files in /var/tmp?
>>>>
>>>> I think this may be why my radmind is taking longer on machines  
>>>> then
>>>> it used to. In some of my user machines, I have found thousands of
>>>> these files:
>>>>
>>>> -rw-------   1 bernsteg  wheel    67331 Mar  6 16:11 45ede718d14b9
>>>> -rw-------   1 bernsteg  wheel    67331 Mar 16 20:03 45fb3e6df3ad6
>>>> -rw-------   1 bernsteg  wheel    67331 Mar 20 17:17 46005d935e15b
>>>> -rw-------   1 bernsteg  wheel    67331 Mar 21 09:24 4601402087693
>>>> -rw-------   1 bernsteg  wheel    67331 Mar 22 07:24 460275944cf99
>>>> -rw-------   1 bernsteg  wheel   363382 Apr  9 11:14 461a667693d52
>>>> -rw-------   1 bernsteg  wheel    64451 Apr  9 11:14 461a667fbe421
>>>> -rw-------   1 bernsteg  wheel  2583475 Apr  9 11:17 461a672aa163f
>>>> -rw-------   1 bernsteg  wheel  2371331 Apr  9 11:18 461a674f78a7f
>>>> -rw-------   1 bernsteg  wheel    81089 Apr  9 11:18 461a6752ec55e
>>>> -rw-------   1 bernsteg  wheel  2371331 Apr  9 11:24 461a68d262d34
>>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a68e084bc4
>>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a690090f51
>>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a6902b3007
>>>> -rw-------   1 bernsteg  wheel    67331 Apr  9 11:26 461a69522b70d
>>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b44a3574
>>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b4743ca5
>>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b47743ea
>>>>
>>>> In most cases they go back to when we first installed their  
>>>> machine.
>>>>
>>>> They seem like something that we can get rid of being they are in a
>>>> folder called tmp. But then again.... I thought I should ask.
>>>> Also, I
>>>> noticed on several machines that the files always start with the
>>>> number 4, but I don't know if that is something I can count on when
>>>> deleting these files. They appear to be some thing to do with
>>>> printers.
>>>>
>>>> Does anyone have any thoughts?
>>>>
>>>> Is anyone managing these files with radmind?
>>>>
>>>> Thanks
>>>> -Gary
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Quade Boman   |   quade@...
>>>> Systems Administrator   |   Beaverton School District
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> ------------------------------------------------------------------- 
>>>> -
>>>> -
>>>> ----
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>>> share your
>>>> opinions on IT & business topics through brief surveys-and earn  
>>>> cash
>>>> http://www.techsay.com/default.php?
>>>> page=join.php&p=sourceforge&CID=DEVDEV_____________________________ 
>>>> _
>>>> _
>>>> ________________
>>>> 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
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> -
>>> ---
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>>
>>> !DSPAM:461b4131133221152467131!
>>> _______________________________________________
>>> Radmind-users mailing list
>>> Radmind-users@...
>>> https://lists.sourceforge.net/lists/listinfo/radmind-users
>>>
>>>
>>> !DSPAM:461b4131133221152467131!
>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Radmind-users mailing list
>> Radmind-users@...
>> https://lists.sourceforge.net/lists/listinfo/radmind-users
>
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * * * * * * * * * * *
> -- "The reward for work well done is the opportunity to do more."
>
> -- "I tried, but it didn't work" is a lot better than "I wish I'd  
> tried."
>
>          Gary R. Bernstein      	Director of Computer Information &
> Access
>          bernsteg@...	Krannert Center for the Performing Arts
>          217-244-1038           	College of Fine & Applied Arts - UIUC
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * * * * * * * * * * *
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Radmind-users mailing list
> Radmind-users@...
> https://lists.sourceforge.net/lists/listinfo/radmind-users
>
> !DSPAM:461b9768184101152467131!
>
>
>

On 4/10/07 10:05 AM, "Andrew Mortensen" <admorten@...> wrote:

>> Do you think it is safe to remove all of /var/tmp then?
> 
> Probably. This line:
> 
> mkdir -p -m 01777 /private/var/tmp /private/tmp
> 
> appears in /etc/rc, so if it is removed, it will get recreated on
> reboot.

Even though it's not cleared on reboot under Tiger (which I found in
researching another issue), it may be valuable for forensics.

Some software used for less-than-angelic purposes (IRC bots, etc.) can be
installed into this location during a break-in ... you may encounter that if
you have weak passwords (even in a directory service) + SSH enabled with its
default (less secure) configuration.

Therefore, weigh your priorities and options before removing the directory
entirely.


-- 
Jeremy Reichman
Senior Desktop Systems Engineer
Information and Technology Services
Rochester Institute of Technology

Indeed, /private/var/tmp is not cleared on reboot like you think it should
be.  I found only a small bit of info out on the web when I first
discovered it.  It was on an Apple list (I can't find it again) where one
of the posters said his Apple bug report on the matter was closed because
"it was behaving as expected."  I'd suggest to still file a bug on it, I'm
going to.



Andrew Mortensen <admorten@...> on Tuesday, April 10, 2007 at 6:14
AM -0800 wrote:
>
>On Apr 10, 2007, at 3:47 AM, Sam Agnew wrote:
>
>> My nightly Radmind script reboots at the end. Is /var/tmp not  
>> cleared on reboot? Hmm... Maybe only /tmp is cleared...
>
>Looks to me like Apple changed that. /var/tmp used to be removed and  
>recreated on reboot by /etc/rc. Now only "/var/tmp/folders.*" is  
>deleted. Filing a bug report is always an option.
>
>andrew
>
>>
>> Sam
>>
>> On 9 Apr 2007, at 21:29, Quade Boman wrote:
>>
>>> I've also recently noticed the large amount of files located in / 
>>> private/var/tmp.  In our case, there is often large files that  
>>> ClamXav leaves behind, eating up hard drive space on older  
>>> machines.  I was going to add a cleaning routine to our nightly  
>>> scripts to remove the contents of this directory.
>>>
>>>
>>>
>>> radmind-users@... on Monday, April 9, 2007 at  
>>> 9:46 AM -0800 wrote:
>>>
>>> Message: 9
>>> Date: Mon, 9 Apr 2007 11:46:33 -0500
>>> From: Gary Bernstein <bernsteg@...>
>>> Subject: [Radmind-users] /var/tmp
>>> To: Radmind mailing list -- Radmind Users
>>>         <radmind-users@...>
>>> Message-ID: <5FF96C21-424B-492F-9690-84C99A216D8B@...>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Has anyone else noticed a growing number of files in /var/tmp?
>>>
>>> I think this may be why my radmind is taking longer on machines then
>>> it used to. In some of my user machines, I have found thousands of
>>> these files:
>>>
>>> -rw-------   1 bernsteg  wheel    67331 Mar  6 16:11 45ede718d14b9
>>> -rw-------   1 bernsteg  wheel    67331 Mar 16 20:03 45fb3e6df3ad6
>>> -rw-------   1 bernsteg  wheel    67331 Mar 20 17:17 46005d935e15b
>>> -rw-------   1 bernsteg  wheel    67331 Mar 21 09:24 4601402087693
>>> -rw-------   1 bernsteg  wheel    67331 Mar 22 07:24 460275944cf99
>>> -rw-------   1 bernsteg  wheel   363382 Apr  9 11:14 461a667693d52
>>> -rw-------   1 bernsteg  wheel    64451 Apr  9 11:14 461a667fbe421
>>> -rw-------   1 bernsteg  wheel  2583475 Apr  9 11:17 461a672aa163f
>>> -rw-------   1 bernsteg  wheel  2371331 Apr  9 11:18 461a674f78a7f
>>> -rw-------   1 bernsteg  wheel    81089 Apr  9 11:18 461a6752ec55e
>>> -rw-------   1 bernsteg  wheel  2371331 Apr  9 11:24 461a68d262d34
>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a68e084bc4
>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a690090f51
>>> -rw-------   1 bernsteg  wheel  2583499 Apr  9 11:25 461a6902b3007
>>> -rw-------   1 bernsteg  wheel    67331 Apr  9 11:26 461a69522b70d
>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b44a3574
>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b4743ca5
>>> -rw-------   1 bernsteg  wheel    12576 Apr  9 11:35 461a6b47743ea
>>>
>>> In most cases they go back to when we first installed their machine.
>>>
>>> They seem like something that we can get rid of being they are in a
>>> folder called tmp. But then again.... I thought I should ask. Also, I
>>> noticed on several machines that the files always start with the
>>> number 4, but I don't know if that is something I can count on when
>>> deleting these files. They appear to be some thing to do with  
>>> printers.
>>>
>>> Does anyone have any thoughts?
>>>
>>> Is anyone managing these files with radmind?
>>>
>>> Thanks
>>> -Gary
>>>
>>>
>>>
>>>
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Quade Boman   |   quade@...
>>> Systems Administrator   |   Beaverton School District
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> --------------------------------------------------------------------- 
>>> ----
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>>> share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php? 
>>> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ 
>>> ________________
>>> 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
>>
>>
>>
>> !DSPAM:461b4131133221152467131!
>> ---------------------------------------------------------------------- 
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>>
>> !DSPAM:461b4131133221152467131!
>> _______________________________________________
>> Radmind-users mailing list
>> Radmind-users@...
>> https://lists.sourceforge.net/lists/listinfo/radmind-users
>>
>>
>> !DSPAM:461b4131133221152467131!
>





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quade Boman   |   quade@...
Systems Administrator   |   Beaverton School District 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Apr 10, 2007, at 10:39 AM, Jeremy Reichman wrote:

> On 4/10/07 10:05 AM, "Andrew Mortensen" <admorten@...> wrote:
>
>>> Do you think it is safe to remove all of /var/tmp then?
>>
>> Probably. This line:
>>
>> mkdir -p -m 01777 /private/var/tmp /private/tmp
>>
>> appears in /etc/rc, so if it is removed, it will get recreated on
>> reboot.
>
> Even though it's not cleared on reboot under Tiger (which I found in
> researching another issue), it may be valuable for forensics.

Maybe. If all you find is an IRC bot, that tells you an IRC bot was  
installed, which was probably obvious from network traffic. Logs can  
be more helpful for understanding method of attack. Tripwire reports  
would be useful if Apple ever provided a system capable of passing  
tripwire. If you're interested in forensics, your best bet is to shut  
down the computer, boot it into FW disk mode, then make a read-only  
disk image of the compromised disk. Since /var/tmp is only cleared  
by /etc/rc during boot, you won't lose anything from that location,  
while additionally having a complete record of the compromised  
machine for examination.

> Some software used for less-than-angelic purposes (IRC bots, etc.)  
> can be
> installed into this location during a break-in ... you may  
> encounter that if
> you have weak passwords (even in a directory service) + SSH enabled  
> with its
> default (less secure) configuration.

Sure, they could use /var/tmp. Or /Volumes. Or /tmp. Or /Users/ 
Shared. All of these are world-writable by default.

> Therefore, weigh your priorities and options before removing the  
> directory
> entirely.

Sage advice.

On 4/10/07 11:03 AM, "Andrew Mortensen" <admorten@...> wrote:

>> Therefore, weigh your priorities and options before removing the
>> directory
>> entirely.
> 
> Sage advice.

And that's all that I was trying to get across. :) Obviously, any negative
space can be used by someone who wants to avoid detection/remediation by
Radmind. However, by clearing unmanaged spaces programmatically and
automatically, you can sometimes -- and hopefully no one comes across these
situations -- lose the chance to perform forensic analysis. However, you may
have also remediated the problem in doing so ... it depends on your
priorities, which should also be driven by the available security policies
within your organization.


-- 
Jeremy Reichman
Senior Desktop Systems Engineer
Information and Technology Services
Rochester Institute of Technology

On 4/10/07 10:59 AM, "Quade Boman" <Quade_Boman@...> wrote:

> Indeed, /private/var/tmp is not cleared on reboot like you think it should be.
> I found only a small bit of info out on the web when I first discovered it.
> It was on an Apple list (I can't find it again) where one of the posters said
> his Apple bug report on the matter was closed because "it was behaving as
> expected."  I'd suggest to still file a bug on it, I'm going to.

Well, I'm going to disagree a bit about /private/var/tmp, since it _is_
documented in the "hier" man page. (Let's disregard, for the moment, that
this man page is from the BSD man pages, dated June 5, 1993, and doesn't
apply terribly well to Mac OS X. That's _another_ bug report, and yes, I've
filed it with Apple. I thought I'd be the only one but it's marked as
"duplicate." <grin>) The man page says:

"/var/tmp/      temporary files that are kept between system reboots"

To me, this sounds _exactly_ the way that /private/var/tmp is behaving in
Tiger. So I'd call this "behaves correctly."

Contrast it to the documentation on /tmp:

"/tmp/          temporary files"


-- 
Jeremy Reichman
Senior Desktop Systems Engineer
Information and Technology Services
Rochester Institute of Technology