Miguel Filho | 2 Jan 22:16 2009
Picon

Some issues with vzpkg2

Hi there,

I'm playing with vzpkg2 and vztmpl, using the most recent code from
the git repository.

Stock OpenVZ kernel and tools from Debian Lenny.

I've built and installed all packages.

1) I was getting this error early on:

[cache-os] ERROR: Cannot create /var/lib/vz/lock/100001.lck lockfile
[cache-os] ERROR: Can't find free VE ID

I've found out that I didn't have the `lockfile` command and the lock
function was failing, but there was no error regarding the missing
command. I've found that the `lockfile` command comes with procmail,
so I installed it and problem solved.

Looking further I've found the dependencies on procmail and gawk in
the spec file. Please consider adding them as a dependency on the
Debian control file too, since Debian comes with old awk by default
and not gawk. Consider adding yum too.

2) After pulling out some hair to find the source for pkg-cacher (not
mentioned on the wiki) and installing it, I got this error latter on
building a Fedora 9 template:

/var/lib/vz/template/fedora/config/install-post: line 8:
NO_PKG_CACHER: unbound variable
(Continue reading)

Marcin Owsiany | 3 Jan 18:10 2009
Picon

Re: Suggestion for a new parameter: PRIMARY_IP

On Sun, Dec 14, 2008 at 03:43:47PM +0000, Marcin Owsiany wrote:
> My suggestion is to add another optional configuration parameter, called
> for example PRIMARY_IP, that, _if_specified_, would be used with
> HOSTNAME to set up the /etc/hosts entry. If it's not specified, then the
> first address from IP_ADDRESS would be used, as usual.

Can developers please comment on this?

regards,
--

-- 
Marcin Owsiany <marcin@...>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
Sterling Windmill | 3 Jan 23:28 2009
Picon

Re: Suggestion for a new parameter: PRIMARY_IP

How do "real" linux distributions handle this?

I would assume we would want to mimic that behavior.

----- Original Message -----
From: "Marcin Owsiany" <marcin-+N/AAJ4KvxfVItvQsEIGlw@public.gmane.org>
To: users-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Sent: Saturday, January 3, 2009 12:10:19 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Users] Suggestion for a new parameter: PRIMARY_IP

On Sun, Dec 14, 2008 at 03:43:47PM +0000, Marcin Owsiany wrote:
> My suggestion is to add another optional configuration parameter, called
> for example PRIMARY_IP, that, _if_specified_, would be used with
> HOSTNAME to set up the /etc/hosts entry. If it's not specified, then the
> first address from IP_ADDRESS would be used, as usual.

Can developers please comment on this?

regards,
--
Marcin Owsiany <marcin-+N/AAJ4KvxfVItvQsEIGlw@public.gmane.org>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
_______________________________________________
Users mailing list
Users-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
https://openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users
Dietmar Maurer | 4 Jan 09:21 2009

RE: Suggestion for a new parameter: PRIMARY_IP

How does adding an additional setting like PRIMARY_IP help? Instead
you can simply change the order of IP_ADDRESS. What is the difference?

- Dietmar

> -----Original Message-----
> From: users-bounces@...
[mailto:users-bounces@...] On
> Behalf Of Marcin Owsiany
> Sent: Samstag, 03. Jänner 2009 18:10
> To: users@...
> Subject: Re: [Users] Suggestion for a new parameter: PRIMARY_IP
> 
> On Sun, Dec 14, 2008 at 03:43:47PM +0000, Marcin Owsiany wrote:
> > My suggestion is to add another optional configuration parameter,
> called
> > for example PRIMARY_IP, that, _if_specified_, would be used with
> > HOSTNAME to set up the /etc/hosts entry. If it's not specified, then
> the
> > first address from IP_ADDRESS would be used, as usual.
> 
> Can developers please comment on this?
Marcin Owsiany | 4 Jan 14:20 2009
Picon

Re: Suggestion for a new parameter: PRIMARY_IP

On Sat, Jan 03, 2009 at 05:28:40PM -0500, Sterling Windmill wrote:
> How do "real" linux distributions handle this? 

On a non-virtualized system you just configure your /etc/hosts and
/etc/network/interfaces the way you like.

OpenVZ in turn rewrites these files with information from the
container's config file on each container boot. The problem is that the
order of the IP addresses in the container's config dictates the order
in both system config files. There is currently no way to make them
different.

--

-- 
Marcin Owsiany <marcin@...>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
Marcin Owsiany | 4 Jan 14:21 2009
Picon

Re: Suggestion for a new parameter: PRIMARY_IP

On Sun, Jan 04, 2009 at 09:21:42AM +0100, Dietmar Maurer wrote:
> How does adding an additional setting like PRIMARY_IP help? Instead
> you can simply change the order of IP_ADDRESS. What is the difference?

Changing the order would influence both /etc/hosts and
/etc/network/interfaces in the same way. I want them different.

--

-- 
Marcin Owsiany <marcin@...>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
Marcin Owsiany | 4 Jan 14:42 2009
Picon

18 zettabytes Commited_AS

Here's a puzzling snippet from /proc/meminfo:

CommitLimit:   5913712 kB
Committed_AS: 18446744073708080708 kB

I noticed that because it makes the memory usage graph produced by munin
mostly unusable (as it scales to the largest value, all other graphs
appear at zero).

It seems to have jumped to that value around October and stays there at
a fairly constant level, only occasionally, for a few minutes or hours,
dropping to something on the order of megabytes.

This is a amd64 debian etch with 2.6.18-ovz-028stab045.2-smp, with 255
days uptime.

There is also another machine, nearly identical HW/kernel, with 268 days
uptime, which has similar Commit* values since July.

There was a similar thread here:
http://forum.openvz.org/index.php?t=msg&goto=12723 but no
explanation...

user_beancounters is at http://owsiany.pl/tmp/2009/01/ubc.txt
Although I don't think that's relevant, as it clearly is an underflow.

--

-- 
Marcin Owsiany <marcin@...>              http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown
Miguel Filho | 5 Jan 02:06 2009
Picon

vzpkg2 on Debian Lenny: some yum bugs

Hello, me again!

Well, my usage of vzpkg2 resulted in more trouble than I would espect,
but that is the fun part, isn't it?

First of all, the yum version in Lenny is 3.2.12. I believe that
version will not change anytime soon, and Lenny will be released (God
knows when) with it. So, IMHO, we better have some workarounds for it.

Here we go again:

1) Yum fails to bootstrap CentOS 5 with this error:

Error: Failure finding best provider of libc.so.6 for ..., exceeded
maximum loop length

Googling around I've found this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496103

Basically adding glibc before all packages does the trick and the
template creation finishes without errors.

Curiously, fedora9 and centos4 work fine.

A manually added glibc to be the first package on minimal.list. Ugly
but functional.

2) Yum fails to bootstrap CentOS 5 again with this error:

File "/var/lib/python-support/python2.5/yum/misc.py", line 278, in
import_key_to_pubring
    ctx = gpgme.Context()
AttributeError: 'module' object has no attribute 'Context'

Once again, I've found this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496137

I did a long research on yum's code and the GPG handling in 3.2.12 is
broken. I talked with James Antill (yum's author) on IRC about this
problem:

<miguelzinho> hi there, I'm using yum 3.2.12 on Debian Lenny with vzpkg2
<miguelzinho> vzpkg2 bootstraps various distros
<miguelzinho> when bootstraping centos5
<miguelzinho> I got this
<miguelzinho> File "/var/lib/python-support/python2.5/yum/misc.py",
line 278, in import_key_to_pubring
<miguelzinho>     ctx = gpgme.Context()
<miguelzinho> AttributeError: 'module' object has no attribute 'Context'
<miguelzinho> i've take a look at the current misc.py and the gpg code
is a little different
<miguelzinho> based on what I see in the current code, returning False
on import_key_to_pubring() and some other functions does not affect
yum's behavior
<miguelzinho> I changed misc.py to always return False on 3.2.12 and
the bootstrap operation works fine
<geppetto> miguelzinho: 3.2.12 is basically unsupported by anyone at this point
<geppetto> miguelzinho: if what you did just disabled pgp on repo
keyrings (possible from my memory) ... then yeh, the fix is fine and
don't worry about it (that functionality wasn't really tested/working
in 3.2.12)
<geppetto> miguelzinho: But you might want to just update to something
more recent (best options: 3.2.19 as in RHEL/CentOS soon, or 3.2.21
when that's released soon)

There you go.

I kept looking and I've found out that vzpkg2 imports the GPG keys
using rpm, before calling yum --installroot.

Plus, the key for the centos-vz-addons repository was not available on
the gpgkeys directory. I've downloaded the key and then yum will not
bother trying importing it, so the bug is not triggered.

I think that's all for now.

Is there any bugtracker that I can report all these stuff?

Regards,

Miguel
Dietmar Maurer | 5 Jan 10:43 2009

RE: Suggestion for a new parameter: PRIMARY_IP

> On Sun, Jan 04, 2009 at 09:21:42AM +0100, Dietmar Maurer wrote:
> > How does adding an additional setting like PRIMARY_IP help? Instead
> > you can simply change the order of IP_ADDRESS. What is the
> difference?
> 
> Changing the order would influence both /etc/hosts and
> /etc/network/interfaces in the same way. I want them different.

The question is why you want that.

> Any process running in a CT that does not explicitly bind() to a
specific 
> address, will have the local endpoint address set to the first one in
> IP_ADDRESS from the CT configuration. [1]

The manual page (ip(7)) states something different. Either you pass an
specific address to bind, or use some special address like INADDR_ANY.
All application I know use gethostbyname to get the address (hostname +
/etc/hosts).

So if you application depends on the order of /etc/network/interfaces
I would consider that an application error. What application are we
talking about? 

- Dietmar
JR Richardson | 5 Jan 20:22 2009
Picon

total system barrier and limit calculations?

Hi All,

Does anyone have a formula or calculations to figure out what the
various beancounter barrier and limit for a paticular host system will
be?

I'm trying to figure out how to divide up the system resources evenly
accross all VE's.  All the VE's are the same and pretty much consume
the same amount of resource accross the board.  I'm also limiting the
number of VE's per host server to 20.  So my idea is to figure out the
max_ulong figures for parameters like the "*buf" "*sock" "kmemsize"
and divide by 20 to set the limits for all the VE's.

I'm currently using the default VE templates for parameter limits and
every now and then, I have to increase or tweak some counters.
Knowing that these VE's are static and the number of VE's does not
change, this solution should be ok to do.

Are there any pitfalls I may run into with this?

Thanks.

JR
--

-- 
JR Richardson
Engineering for the Masses

Gmane