Andrea Righi wrote: > wtautz wrote: > >> Andrea Righi wrote: >> >>> wtautz wrote: >>> >>> >>>> Andrea Righi wrote: >>>> >>>> >>>>> wtautz wrote: >>>>> >>>>> >>>>> >>>>>> Andrea Righi wrote: >>>>>> >>>>>> >>>>>> >>>>>>> wtautz wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, I have noticed that on some autoinstalled clients that >>>>>>>> the root / directory has permissions: >>>>>>>> >>>>>>>> >>>>>>>> drwxr-x--x >>>>>>>> >>>>>>>> where as the golden client has drwxr-xr-x >>>>>>>> >>>>>>>> the golden client is Ubuntu Feisty, amd64 and I used systemimager >>>>>>>> version 3.8.2-2 >>>>>>>> and the same version on the server. >>>>>>>> >>>>>>>> Is this a known behaviour? >>>>>>>> >>>>>>>> walter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> It doesn't seem to happen with 3.9.6, anyway AFAIR nothing have been >>>>>>> changed in >>>>>>> this front, so it's should be the same also with 3.8.2. >>>>>>> >>>>>>> What are the permissions of your image in /var/lib/systemimager/images >>>>>>> on your >>>>>>> image server? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> 0755 root.root >>>>>> >>>>>> >>>>>> >>>>> And what about permissions in your overrides >>>>> (/var/lib/systemimager/overrides/*)? >>>>> >>>>> >>>>> >>>>> >>>> /var/lib/systemimager/overrides# ls -al >>>> total 28 >>>> drwxr-xr-x 6 root root 4096 Sep 6 15:04 . >>>> drwxr-xr-x 5 root root 4096 Sep 18 09:31 .. >>>> -rw-r--r-- 1 root root 2566 Aug 5 14:17 README >>>> drwxr-x--x 2 root root 4096 Aug 28 12:54 cpu-linux-2007-fall >>>> drwxr-x--x 2 root root 4096 Aug 28 15:49 frontend-linux-2007-fall >>>> drwxr-x--x 2 root root 4096 Aug 20 12:21 lwsfall2007 >>>> drwxr-x--x 2 root root 4096 Aug 31 15:02 old-frontend-image >>>> >>>> >>>> which explains what I am seeing.... I guess. Each of these is an empty >>>> directory. >>>> >>>> >>> Yes. If you're using at least one of those overrides the permission bits >>> will be >>> set in the root of the installed client, since overrides are copied after >>> the >>> image (by definition). To resolve just set the appropriate permissions in >>> the >>> override dirs. Anyway I don't know why you've that permission mask, probably >>> it's due to your "umask" setting for root. >>> >>> >>> >> Perhaps you should add a little bit of code to make sure the umask is >> set appropriately? Assuming the problem I am seeing is due to that. >> >> Walter >> >> >> > > Well.. this is the piece of code that creates the override dir after an image > retrieval from a golden client (see > http://svn.systemimager.org/filedetails.php?repname=systemimager&path=%2Ftrunk%2Flib%2FSystemImager%2FServer.pm&rev=0&sc=0 > function create_autoinstall_script): > > ### BEGIN overrides stuff ### > # Create default overrides directory. -BEF- > # > my $override_dir = $config->default_override_dir; > my $dir = "$override_dir/$script_name"; > if (! -d "$dir") { > mkdir("$dir", 0755) or die "FATAL: Can't make directory $dir\n"; > } > > It means that if an override dir doesn't exist it's created using the right > permissions 0755. > Perhaps explicitly checking that the mode is correct is necessary. If one reads the description of mkdir in the perl book mkdir FILENAME, MASK where "MASK as modified by the current umask". So it would seem that the umask setting clearly effects how the mkdir command works. It might be better to create the directory and then use chmod after the fact?
Walter > Are you sure that you didn't create it manually? For example you could try to > check the image retrieval time (with si_lsimage -v) and compare it with the > date > of the override directories... > > -Andrea > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
