Re: anaconda-d] Re: FC3 working anaconda todo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 30 May 2004, R P Herrold wrote:

> On Sat, 29 May 2004, Tom Diehl wrote:
> 
> > When I wrote the above I was thinking about this, which is from the
> > dhcp-options man page:
> > 
> > option ntp-servers ip-address [, ip-address...  ];
> 
> interesting -- not in mine.  does teh amn page for your dhcp 
> client indicate it can catch what the DHCP server pitches?

My memory tells me yes. :-) In addition the dhclient.conf man page says the
following:

There  is  a variety of data contained in offers that DHCP servers send
       to DHCP clients.  The data that can be specifically requested  is  what
       are called DHCP Options.  DHCP Options are defined in
        dhcp-options(5).

       The request statement

        request [ option ] [, ... option ];

       The  request  statement  causes  the  client to request that any server
       responding to the client send the client its values for  the  specified
       options.    Only  the  option  names should be specified in the request
       statement - not  option  parameters.    By  default,  the  DHCP  server
       requests  the  subnet-mask,  broadcast-address,  time-offset,  routers,
       domain-name, domain-name-servers, host-name,  nis-domain,  nis-servers,
       and ntp-servers options.
           ^^^^^^^^^^
           ^^^^^^^^^^

What are you using? I have a mix of RHL8.0-FC1 including some RHEL3 machines
and the options appear in the man pages of all of them.

> > > interested in tools to automate the generation of a well 
> > > formed ntp.conf (and friends) based on information handed out 
> > > from the DHCP server, but do not know of a mechanism for the 
> > > dhcp server to do it.
> > 
> > I think that if you have the ntp servers and TZ that should be enough info for
> > most installations. Am I missing something?
> 
> for a client, probably not, except that there is the ability 
> to do cryptograpgically secured time exchange, to avoid MitM 
> attacks (kerberos replay comes to mind), which needs some 
> configuring.

But that could be done post install. The original question was simply how to
get the clock set correctly pre-install to avoid systems looking like they
have been installed back in the 80's 0r 90's.

Regards,

Tom



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux