On Thu, Sep 11, 2008 at 3:48 PM, Joseph Boyer Jr. <[EMAIL PROTECTED]> wrote:
> Umaks is set in /etc/bashrc and is 022 by default for rhel systems.
>
>
> What I suspect is that the owner of your directories has changed. What user
> does tftpd run as? By default tftpd runs as nobody, but if you specify the -u
> (for user) option in the server_args line of /etc/xinetd.d/tftpd you can set
> there perms on the directories and files to be 700 and 600 if everything is
> owned by the user given to the -u option for tftpd.
>
Hmmm the file looks to be upstream default as
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
I am guessing someone did a chmod and didn't tell me.
>
> Just a thought
>
>
> Joseph Boyer Jr
> Enterprise Technology Services
> Liquidnet Holdings, Inc.
> [EMAIL PROTECTED]
> T +1 646.660.8352
> C +1 646.284.8394
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen John
> Smoogen
> Sent: Thursday, September 11, 2008 2:00 PM
> To: cobbler mailing list
> Subject: Re: Interesting issue with cobbler and EL-5
>
> On Thu, Sep 11, 2008 at 8:33 AM, Michael DeHaan <[EMAIL PROTECTED]> wrote:
>> Stephen John Smoogen wrote:
>>> An interesting issue came up today with our RHEL-5 system running
>>> cobbler. We had not built a system in a couple of days, and had not
>>> seen any issues. Today of the systems could get tftp images from the
>>> box. They kept getting permission denied. For some reason the files in
>>> /tftpboot/images were 0600 (and directories 0700) which must have
>>> worked last week but did not today. the reason is that the EL-5 tftpd
>>> daemon gets the pxecfg.conf file as root but becomes nobody and could
>>> not get any of the scripts below it. Changing the permissions to 0644
>>> and 0755 fixed the issue.
>>>
>>> Now why did it work last week? I don't know.. I can't see any config
>>> file changes that would have allowed it to do so..
>>>
>>>
>>
>> Has anyone else seen this problem? This is the first I've heard of it.
>>
>> We could possibly not be setting umask correctly but nothing has changed
>> in this area of the code for a long time, so I'd be more likely to suspect
>> something external was adjusting your permissions.
>>
>
> Hmmm maybe. What should the umask for those directories be by default?
>
>
>
>
> --
> Stephen J Smoogen. -- BSD/GNU/Linux
> How far that little candle throws his beams! So shines a good deed
> in a naughty world. = Shakespeare. "The Merchant of Venice"
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
>
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
