[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111102085635.GB2096@openwall.com>
Date: Wed, 2 Nov 2011 12:56:35 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: vzctl update
On Mon, Oct 31, 2011 at 11:31:56PM +0400, Dmitry V. Levin wrote:
> Are you sure I'm the right person to update vzctl?
I doubt that anyone else on our team would do it better. So I'd be
happy if you do it.
> I passed the maintenance of this package in Sisyphus to another person
> after vzctl-3.0.24.2 release, which was about 10 months ago. Also,
> I haven't migrated to 2.6.32 stable kernels yet, so I still use 2.6.18
> stable kernels.
The major changes in vzctl were between 3.0.23 and .24, and we're also
still using the rhel5'ish kernels (although this should change soon).
So it sounds like you have the experience needed for this update.
> On Sat, Oct 29, 2011 at 01:21:06PM +0400, Solar Designer wrote:
> > 1. As far as I'm aware, newer vzctl dropped the use of cron jobs in
> > favor of some event notification mechanism (which I am totally
> > unfamiliar with). However, I think they have no equivalent to this cron
> > job that we add with vzctl-3.0.23-owl-cron.diff:
[...]
> > Is this understanding correct?
>
> Yes, it seems to be correct.
>
> > If so, would you re-introduce the cron
> > jobs mechanism just for this specific cron job? If so, I think this
> > change would need to be submitted upstream.
>
> The schedule for this cron job is not obvious.
Yes, but we need to provide some reasonable default. Not having this
cron job at all is problematic.
...or maybe something like this should be implemented in the kernel,
with the interval controllable via a sysctl. But we don't have that yet.
> > 2. I think the MODULES_DISABLED setting should accept more than just yes
> > or no. Maybe it should be made tri-state, with the extra value called,
> > say, "optional" (meaning to disable optional modules only, but load the
> > required ones). Or maybe it should accept a list of modules to disable.
>
> I don't like this MODULES_DISABLED control, IMHO it is rarely useful.
> What sysadmin needs is a simple way to control the list of modules, not
> just a control to disable the feature altogether. The traditional
> solution would be to have a reasonable default value for each of these
> module lists, which local administrator can override.
>
> For example, /etc/init.d/vz could do
> . /usr/share/vzctl/vz-modules
> to have these safe defaults loaded.
I'd be fine with that as well, especially if you can get this approach
and the patch accepted upstream (perhaps discuss it with Kir first).
On the other hand, if I have to work on a vzctl update for Owl myself, I
am likely to just introduce a hack into MODULES_DISABLED (a third
possible value or a list of modules to disable).
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
