Re: [zones-discuss] NTP client in non-global zone
Jeff Victor writes:
> On Thu, Feb 19, 2009 at 9:54 AM, Timothy Kennedy
> 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
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
On Thu, Feb 19, 2009 at 9:54 AM, Timothy Kennedy 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
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
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 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
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
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.
> +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.
--
James Carlson, Solaris Networking
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
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
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
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
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
