Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread Paul Davis





NTP client should not be configured in zones. One kernel, one clock.

This is also from the FAQ:

Q: Can some non-global zones have different date and/or time
settings (i.e. different clocks)?
A: Although different zones can have 'be' in different time zones, each
zone gets its date and time clock from the same source. This means that
the time zone setting gets applied after the current time data is
obtained from the kernel.
If you would like the ability to have different clock sources per zone,
please add a call record to RFE 5033497. [August 2005]

HTH,
Paul


Charles Meo wrote:

  Just had a look at the FAQ and found this:

Q: Can a zone be an NTP server?
A: Because the NTP server software also sets the time clock, which a 
non-global zone cannot be allowed to do, a zone cannot be an NTP server. 
(June 2005) 

What about client? If I don't enable ntp in a non-global zone, is it 
sufficient to enable it in the global zone? If I do set up a client, I get 
this:

Can't adjust time: Not owner

But ntpq -p works fine and shows it is talking.

My suggestions are that 1. xntpd should detect that it's in a zone, and 
either quit squawking or stop trying to set the time, or 2. that it should 
 just exit as quietly as possible--as long as the time gets set somehow.

The current 'solution' of letting it sort of run and spew out loads of 
warnings strikes me as half-baked. Isn't this a bug?

What is best practice here?

Regards,

Charles Meo
Infrastructure Team Leader
LTX Pty Ltd 
Phone: 03 8699 7900 
Mobile: 0409 258 471 
Email: charles@ltx.com.au
Website: www.ltx.com.au



Unencrypted electronic mail is not secure and may be intercepted, 
modified, or otherwise interfered with during delivery. If you have any 
doubts as to the authenticity of the sender or the contents of this email, 
please contact us immediately by telephone to confirm. This electronic 
transmission is intended only for those to whom it is addressed. It may 
contain information that is confidential, privileged or exempt from 
disclosure by law. Any claim to privilege is not waived or lost by reason 
of mistaken transmission of this information. If you are not the intended 
recipient, you must not distribute or copy this transmission and should 
immediately notify the sender. Your costs for doing this will be 
reimbursed by the sender. This email is also subject to copyright. No part 
of it should be reproduced, adapted or communicated without the written 
consent of the copyright owner. Any personal information in this email 
must be handled in accordance with the Privacy Act 1988 (Cth). 
___
zones-discuss mailing list
zones-discuss@opensolaris.org
  


-- 
Paul Davis
Technical Specialist
Sun Professional Services
500 Eldorado Blvd., UBRM05
Broomfield, Colorado 80021
Office: 720-895-1645
Cell:   303-570-1092








___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread David . Comay

What is best practice here?


Do not run {x}ntpd in the zones.


Actually there is a use-case for doing so - given that it's a
network-facing appliction, one might want to run xntpd in a non-global
zone for isolation reasons.
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread Nicolas Dorfsman


Le 19 févr. 09 à 09:13, david.co...@sun.com a écrit :


What is best practice here?


Do not run {x}ntpd in the zones.


Actually there is a use-case for doing so - given that it's a
network-facing appliction, one might want to run xntpd in a non-global
zone for isolation reasons.


+1

It would be a great idea to have a easy solution to give these  
privileges to a zone.

smime.p7s
Description: S/MIME cryptographic signature
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread Nicolas Dorfsman


Le 19 févr. 09 à 14:02, James Carlson a écrit :


Nicolas Dorfsman writes:

Le 19 févr. 09 à 09:13, david.co...@sun.com a écrit :


What is best practice here?


Do not run {x}ntpd in the zones.


Actually there is a use-case for doing so - given that it's a
network-facing appliction, one might want to run xntpd in a non- 
global

zone for isolation reasons.


To expound on that a bit: non-global zones can have access to networks
that the global zone cannot talk to.  In these cases, it's possible
for NTP to be configured to serve out time even if it can't manage the
time on the system.  The disable pll option in ntp.conf would be
used to set up such a server.


Idea is to have one particular non-globale zone setting the time for  
the whole machine.





+1

It would be a great idea to have a easy solution to give these
privileges to a zone.___


See zonecfg(1M) ... that specific case is in the examples for the
limitpriv attribute.


I'll do.
I've said easy.  ;-)

smime.p7s
Description: S/MIME cryptographic signature
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread James Carlson
Nicolas Dorfsman writes:
 Le 19 févr. 09 à 14:02, James Carlson a écrit :
  To expound on that a bit: non-global zones can have access to networks
  that the global zone cannot talk to.  In these cases, it's possible
  for NTP to be configured to serve out time even if it can't manage the
  time on the system.  The disable pll option in ntp.conf would be
  used to set up such a server.
 
 Idea is to have one particular non-globale zone setting the time for  
 the whole machine.

Yes; that's another way to run.  And it's such a good idea that it's
already supported and documented.  ;-}

-- 
James Carlson, Solaris Networking  james.d.carl...@sun.com
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread Timothy Kennedy



Nicolas Dorfsman wrote:
It would be a great idea to have a easy solution to give these 
privileges to a zone.


in zonecfg for a given zone,
set limitpriv=default,proc_lock_memory,proc_priocntl,sys_time

David Comay has an interesting blog post on this that can be found
here: http://blogs.sun.com/comay/entry/privilege_set_me_free
that explains the reasons for permissions additional to sys_time.

-Tim


--
Timothy Kennedy
SDE Infrastructure Operations Manager
Email:  timothy.kenn...@sun.com
Phone:  +1-703-636-0531 / x53151
AIM/Skype: tkSUNW
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread Jeff Victor
On Thu, Feb 19, 2009 at 9:54 AM, Timothy Kennedy
timothy.kenn...@sun.com wrote:


 Nicolas Dorfsman wrote:

 It would be a great idea to have a easy solution to give these privileges
 to a zone.

 in zonecfg for a given zone,
 set limitpriv=default,proc_lock_memory,proc_priocntl,sys_time

 David Comay has an interesting blog post on this that can be found
 here: http://blogs.sun.com/comay/entry/privilege_set_me_free
 that explains the reasons for permissions additional to sys_time.

Here's another one: http://blogs.sun.com/JeffV/entry/shrink_wrap_security1 .

You'd think I would have updated the FAQ by now...  :-(

I just updated it, but changed it to NTP client.  I don't know NTP
well enough to know if a zone can be an NTP *server*. If anyone knows
Sun's position on this, I will add it to the FAQ.


-- 
--JeffV
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] NTP client in non-global zone

2009-02-19 Thread James Carlson
Jeff Victor writes:
 On Thu, Feb 19, 2009 at 9:54 AM, Timothy Kennedy
 timothy.kenn...@sun.com wrote:
 
 
  Nicolas Dorfsman wrote:
 
  It would be a great idea to have a easy solution to give these privileges
  to a zone.
 
  in zonecfg for a given zone,
  set limitpriv=default,proc_lock_memory,proc_priocntl,sys_time
 
  David Comay has an interesting blog post on this that can be found
  here: http://blogs.sun.com/comay/entry/privilege_set_me_free
  that explains the reasons for permissions additional to sys_time.
 
 Here's another one: http://blogs.sun.com/JeffV/entry/shrink_wrap_security1 .
 
 You'd think I would have updated the FAQ by now...  :-(
 
 I just updated it, but changed it to NTP client.  I don't know NTP
 well enough to know if a zone can be an NTP *server*. If anyone knows
 Sun's position on this, I will add it to the FAQ.

Being a server is easier than being a client.  Clients have to adjust
the local system time, or they're not doing anything useful.  A server
can broadcast the time without actually being in control of the local
system time (disable pll).

-- 
James Carlson, Solaris Networking  james.d.carl...@sun.com
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] NTP client in non-global zone

2009-02-18 Thread Thomas Törnblom

Charles Meo skrev:

Just had a look at the FAQ and found this:

Q: Can a zone be an NTP server?
A: Because the NTP server software also sets the time clock, which a 
non-global zone cannot be allowed to do, a zone cannot be an NTP server. 
(June 2005) 

What about client? If I don't enable ntp in a non-global zone, is it 
sufficient to enable it in the global zone? If I do set up a client, I get 
this:


Can't adjust time: Not owner

But ntpq -p works fine and shows it is talking.



All zones gets the time from the single kernel running on the system, so 
running ntp on the global zone is sufficient to control time in the NG 
zones as well.



My suggestions are that 1. xntpd should detect that it's in a zone, and 
either quit squawking or stop trying to set the time, or 2. that it should 
 just exit as quietly as possible--as long as the time gets set somehow.


The current 'solution' of letting it sort of run and spew out loads of 
warnings strikes me as half-baked. Isn't this a bug?


There need be no zones awareness in {x}ntpd as there is no reason to run 
it in a NG zone. If it can't adjust the systems time, it is useless anyway.




What is best practice here?


Do not run {x}ntpd in the zones.



Regards,

Charles Meo
Infrastructure Team Leader
LTX Pty Ltd 
Phone: 03 8699 7900 
Mobile: 0409 258 471 
Email: charles@ltx.com.au

Website: www.ltx.com.au



Thomas
___
zones-discuss mailing list
zones-discuss@opensolaris.org