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. > > Are you sure that you didn't create it manually? Quite sure. I did NOT create them.
Walter ------------------------------------------------------------------------- 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
