OpenVZ Forum


Home » Mailing lists » Users » OpenVZ kernel RPM name
OpenVZ kernel RPM name [message #7505] Mon, 16 October 2006 14:32 Go to next message
Dag Wieers is currently offline  Dag Wieers
Messages: 9
Registered: October 2006
Junior Member
Hi,

Yet another mail. The official openvz kernel RPMs are named in such a way
that it causes problems. Tools like yum and apt make a special case about
kernel RPM files because multiple of these can be installed next to each
other.

Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
change the name of the OpenVZ kernel package from:

ovzkernel-2.6.9-023stab030.1-smp
to:
kernel-smp-2.6.9-42.0.3.ovz.1

This would make it more clear to people what it is based on and would make
apt and yum work with those kernels by default.

Kind regards,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
Re: OpenVZ kernel RPM name [message #7542 is a reply to message #7505] Mon, 16 October 2006 23:03 Go to previous messageGo to next message
Kirill Kolyshkin is currently offline  Kirill Kolyshkin
Messages: 9
Registered: October 2006
Junior Member
I though that (at least) yum detects "install-only" packages by their
'provides', not by name. I might be wrong with that though...here's a
relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):

for instpkg in conf.installonlypkgs:
for m in mems:
if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
and m.ts_state in ('i', 'u'):

I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()' is
the piece of code which helps in this scenario.

We name our kernel packages as 'ovzkernel...' just because we don't want to
mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should not
be treated uniformly, otherwise yum will "upgrade" OpenVZ
2.6.16-basedkernel with stock
2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends on
something that ovzkernel provides might help, but I'm not sure.

So, if yum can handle this, we'd rather not change the ovzkernel package
name. I'm not sure about apt though.

On 10/16/06, Dag Wieers <dag@wieers.com> wrote:
>
> Hi,
>
> Yet another mail. The official openvz kernel RPMs are named in such a way
> that it causes problems. Tools like yum and apt make a special case about
> kernel RPM files because multiple of these can be installed next to each
> other.
>
> Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
> change the name of the OpenVZ kernel package from:
>
> ovzkernel-2.6.9-023stab030.1-smp
> to:
> kernel-smp-2.6.9-42.0.3.ovz.1
>
> This would make it more clear to people what it is based on and would make
> apt and yum work with those kernels by default.
>
> Kind regards,
> -- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
> [all I want is a warm bed and a kind word and unlimited power]
Re: OpenVZ kernel RPM name [message #7724 is a reply to message #7542] Mon, 23 October 2006 08:36 Go to previous messageGo to next message
Dag Wieers is currently offline  Dag Wieers
Messages: 9
Registered: October 2006
Junior Member
On Tue, 17 Oct 2006, Kirill Kolyshkin wrote:
>
> On 10/16/06, Dag Wieers <dag@wieers.com> wrote:
>
> > Yet another mail. The official openvz kernel RPMs are named in such a way
> > that it causes problems. Tools like yum and apt make a special case about
> > kernel RPM files because multiple of these can be installed next to each
> > other.
> >
> > Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
> > change the name of the OpenVZ kernel package from:
> >
> > ovzkernel-2.6.9-023stab030.1-smp
> > to:
> > kernel-smp-2.6.9-42.0.3.ovz.1
> >
> > This would make it more clear to people what it is based on and would make
> > apt and yum work with those kernels by default.
>
> I though that (at least) yum detects "install-only" packages by their
> 'provides', not by name. I might be wrong with that though...here's a
> relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):
>
> for instpkg in conf.installonlypkgs:
> for m in mems:
> if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
> and m.ts_state in ('i', 'u'):
>
> I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()' is
> the piece of code which helps in this scenario.

It's possible, still I don't see why you would deviate from the standard
name. The functionality is most likely introduced to consider kernel-smp
and kernel-bigmem as an alternative to kernel.

Nevertheless, this doesn't work for apt. kernel-ovz might work, but the
proper way to tag a package is in the version or release tags. Not the
package-name.


> We name our kernel packages as 'ovzkernel...' just because we don't want to
> mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should not
> be treated uniformly, otherwise yum will "upgrade" OpenVZ
> 2.6.16-basedkernel with stock
> 2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends on
> something that ovzkernel provides might help, but I'm not sure.

People should restrict what packages they use from what repsitory they
have enabled and/or exceptions. Having ovzkernel will not prevent
additional kernel packages to be updated and potentially replacing the ovz
kernel in grub. Especially when like in our case, we like to have the
stock kernel available for disaster recovery, troubleshooting or
vendor-support.

So I don't see the purpose of renaming the ovz kernel package to
ovzkernel. Users still need to check what kernel is in place and verify
before rebooting. If anything, it gives a false sense of security or
causes more confusing.

Especially when documentation and forums refer to the following
command to list the available kernels:

rpm -q kernel
or rpm -qa 'kernel-*'

Proper standards should try to reduce the amount of 'expert' information.
Needing to know that the openvz kernel is called ovzkernel is useless
information by any means.

Kind regards,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
Re: [Users] OpenVZ kernel RPM name [message #8128 is a reply to message #7724] Wed, 08 November 2006 18:17 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

Dag, all,

As you might be aware we have switched to name our kernel rpm just
'kernel' in the latest devel release.

Apparently, it broke the yum update procedure. New kernel is not
recognized by yum, even if it provides vzkernel. I have tried with a
kernel package which also 'Provides: ovzkernel = 2.6.18-ovz028test002'
but that doesn't change the situation. I will now try with 'Obsoletes:
ovzkernel' but this solution is rough since it will probably uninstall
the previous kernel (depends on yum version perhaps).

I have also try "new install" scenario on my FC5 system, it works but
with a bad side effect:

Dependencies Resolved

============================================================ =================
Package Arch Version Repository Size
============================================================ =================
Installing:
vzctl i386 3.0.12-1 openvz 114 k
vzquota i386 3.0.9-1 openvz 47 k
Removing:
kernel i686 2.6.18-1.2200.fc5
installed 39 M
Installing for dependencies:
kernel i686 2.6.18-ovz028test002.1
openvz-kernel-devel 11 M

I.e. it tries to remove the latest FC5 kernel :-\ Too bad, I don't want
that...

Perhaps somebody has a way to fix that?

Dag Wieers wrote:
> On Tue, 17 Oct 2006, Kirill Kolyshkin wrote:
>
>> On 10/16/06, Dag Wieers <dag@wieers.com> wrote:
>>
>>
>>> Yet another mail. The official openvz kernel RPMs are named in such a way
>>> that it causes problems. Tools like yum and apt make a special case about
>>> kernel RPM files because multiple of these can be installed next to each
>>> other.
>>>
>>> Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
>>> change the name of the OpenVZ kernel package from:
>>>
>>> ovzkernel-2.6.9-023stab030.1-smp
>>> to:
>>> kernel-smp-2.6.9-42.0.3.ovz.1
>>>
>>> This would make it more clear to people what it is based on and would make
>>> apt and yum work with those kernels by default.
>>>
>> I though that (at least) yum detects "install-only" packages by their
>> 'provides', not by name. I might be wrong with that though...here's a
>> relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):
>>
>> for instpkg in conf.installonlypkgs:
>> for m in mems:
>> if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
>> and m.ts_state in ('i', 'u'):
>>
>> I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()' is
>> the piece of code which helps in this scenario.
>>
>
> It's possible, still I don't see why you would deviate from the standard
> name. The functionality is most likely introduced to consider kernel-smp
> and kernel-bigmem as an alternative to kernel.
>
> Nevertheless, this doesn't work for apt. kernel-ovz might work, but the
> proper way to tag a package is in the version or release tags. Not the
> package-name.
>
>
>
>> We name our kernel packages as 'ovzkernel...' just because we don't want to
>> mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should not
>> be treated uniformly, otherwise yum will "upgrade" OpenVZ
>> 2.6.16-basedkernel with stock
>> 2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends on
>> something that ovzkernel provides might help, but I'm not sure.
>>
>
> People should restrict what packages they use from what repsitory they
> have enabled and/or exceptions. Having ovzkernel will not prevent
> additional kernel packages to be updated and potentially replacing the ovz
> kernel in grub. Especially when like in our case, we like to have the
> stock kernel available for disaster recovery, troubleshooting or
> vendor-support.
>
> So I don't see the purpose of renaming the ovz kernel package to
> ovzkernel. Users still need to check what kernel is in place and verify
> before rebooting. If anything, it gives a false sense of security or
> causes more confusing.
>
> Especially when documentation and forums refer to the following
> command to list the available kernels:
>
> rpm -q kernel
> or rpm -qa 'kernel-*'
>
> Proper standards should try to reduce the amount of 'expert' information.
> Needing to know that the openvz kernel is called ovzkernel is useless
> information by any means.
>
> Kind regards,
> -- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
> [all I want is a warm bed and a kind word and unlimited power]
> _______________________________________________
> Users mailing list
> Users@openvz.org
> https://openvz.org/mailman/listinfo/users
>
>
Re: Re: [Users] OpenVZ kernel RPM name [message #8243 is a reply to message #8128] Sat, 11 November 2006 12:11 Go to previous messageGo to next message
Dag Wieers is currently offline  Dag Wieers
Messages: 9
Registered: October 2006
Junior Member
On Wed, 8 Nov 2006, Kir Kolyshkin wrote:

> Dag Wieers wrote:
> > On Tue, 17 Oct 2006, Kirill Kolyshkin wrote:
> > > On 10/16/06, Dag Wieers <dag@wieers.com> wrote:
> > >
> > > > Yet another mail. The official openvz kernel RPMs are named in such a
> > > > way
> > > > that it causes problems. Tools like yum and apt make a special case
> > > > about
> > > > kernel RPM files because multiple of these can be installed next to each
> > > > other.
> > > >
> > > > Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
> > > > change the name of the OpenVZ kernel package from:
> > > >
> > > > ovzkernel-2.6.9-023stab030.1-smp
> > > > to:
> > > > kernel-smp-2.6.9-42.0.3.ovz.1
> > > >
> > > > This would make it more clear to people what it is based on and would
> > > > make
> > > > apt and yum work with those kernels by default.
> > > >
> > > I though that (at least) yum detects "install-only" packages by their
> > > 'provides', not by name. I might be wrong with that though...here's a
> > > relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):
> > >
> > > for instpkg in conf.installonlypkgs:
> > > for m in mems:
> > > if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
> > > and m.ts_state in ('i', 'u'):
> > >
> > > I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()'
> > > is
> > > the piece of code which helps in this scenario.
> > >
> >
> > It's possible, still I don't see why you would deviate from the standard
> > name. The functionality is most likely introduced to consider kernel-smp and
> > kernel-bigmem as an alternative to kernel.
> >
> > Nevertheless, this doesn't work for apt. kernel-ovz might work, but the
> > proper way to tag a package is in the version or release tags. Not the
> > package-name.
> >
> >
> > > We name our kernel packages as 'ovzkernel...' just because we don't want
> > > to
> > > mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should
> > > not
> > > be treated uniformly, otherwise yum will "upgrade" OpenVZ
> > > 2.6.16-basedkernel with stock
> > > 2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends
> > > on
> > > something that ovzkernel provides might help, but I'm not sure.
> > >
> >
> > People should restrict what packages they use from what repsitory they have
> > enabled and/or exceptions. Having ovzkernel will not prevent additional
> > kernel packages to be updated and potentially replacing the ovz kernel in
> > grub. Especially when like in our case, we like to have the stock kernel
> > available for disaster recovery, troubleshooting or vendor-support.
> >
> > So I don't see the purpose of renaming the ovz kernel package to ovzkernel.
> > Users still need to check what kernel is in place and verify before
> > rebooting. If anything, it gives a false sense of security or causes more
> > confusing.
> >
> > Especially when documentation and forums refer to the following command to
> > list the available kernels:
> >
> > rpm -q kernel
> > or rpm -qa 'kernel-*'
> >
> > Proper standards should try to reduce the amount of 'expert' information.
> > Needing to know that the openvz kernel is called ovzkernel is useless
> > information by any means.
>
> Dag, all,
>
> As you might be aware we have switched to name our kernel rpm just 'kernel' in
> the latest devel release.
>
> Apparently, it broke the yum update procedure. New kernel is not recognized by
> yum, even if it provides vzkernel. I have tried with a kernel package which
> also 'Provides: ovzkernel = 2.6.18-ovz028test002' but that doesn't change the
> situation. I will now try with 'Obsoletes: ovzkernel' but this solution is
> rough since it will probably uninstall the previous kernel (depends on yum
> version perhaps).
>
> I have also try "new install" scenario on my FC5 system, it works but with a
> bad side effect:
>
> Dependencies Resolved
>
> ============================================================ =================
> Package Arch Version Repository Size
> ============================================================ =================
> Installing:
> vzctl i386 3.0.12-1 openvz 114 k
> vzquota i386 3.0.9-1 openvz 47 k
> Removing:
> kernel i686 2.6.18-1.2200.fc5 installed 39 M
> Installing for dependencies:
> kernel i686 2.6.18-ovz028test002.1 openvz-kernel-devel
> 11 M
>
> I.e. it tries to remove the latest FC5 kernel :-\ Too bad, I don't want
> that...
>
> Perhaps somebody has a way to fix that?

Might this be because your system is configured to hold not more than X
number of kernels ? I see no reason why a new kernel would cause an old
kernel to be removed if there's no obsolete statement, except if there's a
LIFO mechanism to push old kernels out.

I'm interested to see the SPEC file and debug the problem.

Also I noticed that the ovz kernel had no internal changelog. I do
understand that if it is based on the RHEL kernel, there is no real need
to list the Red Hat changes. But having (fictitious) statements in the
changelog like:

* Sun Nov 12 OpenVZ kernel developer 2
- Fixed a conditional kernel oops when <the shit hits the fan>
- Improved locking in the <ultra-glue whoosy bits>
- Fixed a security problem due to UBC counter overflow

* Sat Nov 11 OpenVZ Kernel developer 1
- Fixed bug M, BU Y and bug Z
- Removed CONFIG_ABC and CONFIG_DEF
- Based on RHEL4 kernel X.Y.Z

would give a better understanding what we have in our hands. Especially if
the versioning is not related to the upstream kernel. If we need to apply
an update (and reboot the server) we prefer to know what the change/impact
is and how important the update is.

Kind regards,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
Re: Re: [Users] OpenVZ kernel RPM changelog [message #8459 is a reply to message #8243] Mon, 20 November 2006 13:31 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

Dag Wieers wrote:
> Also I noticed that the ovz kernel had no internal changelog. I do
> understand that if it is based on the RHEL kernel, there is no real need
> to list the Red Hat changes. But having (fictitious) statements in the
> changelog like:
>
> * Sun Nov 12 OpenVZ kernel developer 2
> - Fixed a conditional kernel oops when <the shit hits the fan>
> - Improved locking in the <ultra-glue whoosy bits>
> - Fixed a security problem due to UBC counter overflow
>
> * Sat Nov 11 OpenVZ Kernel developer 1
> - Fixed bug M, BU Y and bug Z
> - Removed CONFIG_ABC and CONFIG_DEF
> - Based on RHEL4 kernel X.Y.Z
>
> would give a better understanding what we have in our hands. Especially if
> the versioning is not related to the upstream kernel. If we need to apply
> an update (and reboot the server) we prefer to know what the change/impact
> is and how important the update is.
>
We could automatically fetch that stuff from GIT and put it into
%changelog, if that's really required. But for me it looks like a
duplication of information (which is already available from other
place). More to say, the changelog could be rather big, with 100s of
entries.

Perhaps we could use short-style changelog, like this (for 028test005
kernel):

- FUSE support.
- Critical scheduler bug fixes
- Miscellaneous bug and compilation fixes
- Code cleanups.

So, which solution would you prefer?
Re: Re: [Users] OpenVZ kernel RPM name [message #8463 is a reply to message #8243] Mon, 20 November 2006 14:01 Go to previous message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

Dag Wieers wrote:
> On Wed, 8 Nov 2006, Kir Kolyshkin wrote:
>
>
>> Dag Wieers wrote:
>>
>>> On Tue, 17 Oct 2006, Kirill Kolyshkin wrote:
>>>
>>>> On 10/16/06, Dag Wieers <dag@wieers.com> wrote:
>>>>
>>>>
>>>>> Yet another mail. The official openvz kernel RPMs are named in such a
>>>>> way
>>>>> that it causes problems. Tools like yum and apt make a special case
>>>>> about
>>>>> kernel RPM files because multiple of these can be installed next to each
>>>>> other.
>>>>>
>>>>> Because OpenVZ name their kernel ovzkernel, this is not possible. Can we
>>>>> change the name of the OpenVZ kernel package from:
>>>>>
>>>>> ovzkernel-2.6.9-023stab030.1-smp
>>>>> to:
>>>>> kernel-smp-2.6.9-42.0.3.ovz.1
>>>>>
>>>>> This would make it more clear to people what it is based on and would
>>>>> make
>>>>> apt and yum work with those kernels by default.
>>>>>
>>>>>
>>>> I though that (at least) yum detects "install-only" packages by their
>>>> 'provides', not by name. I might be wrong with that though...here's a
>>>> relevant section of /usr/lib/yum-plugins/installonlyn.py (yum-2.6.1):
>>>>
>>>> for instpkg in conf.installonlypkgs:
>>>> for m in mems:
>>>> if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
>>>> and m.ts_state in ('i', 'u'):
>>>>
>>>> I'm not yum expert but it seems that 'instpkg in m.po.getProvidesNames()'
>>>> is
>>>> the piece of code which helps in this scenario.
>>>>
>>>>
>>> It's possible, still I don't see why you would deviate from the standard
>>> name. The functionality is most likely introduced to consider kernel-smp and
>>> kernel-bigmem as an alternative to kernel.
>>>
>>> Nevertheless, this doesn't work for apt. kernel-ovz might work, but the
>>> proper way to tag a package is in the version or release tags. Not the
>>> package-name.
>>>
>>>
>>>
>>>> We name our kernel packages as 'ovzkernel...' just because we don't want
>>>> to
>>>> mess with usual non-openvz kernels. OpenVZ and non-OpenVZ kernel should
>>>> not
>>>> be treated uniformly, otherwise yum will "upgrade" OpenVZ
>>>> 2.6.16-basedkernel with stock
>>>> 2.6.18 -- which is a wrong thing to do. Well, the fact that vzctl depends
>>>> on
>>>> something that ovzkernel provides might help, but I'm not sure.
>>>>
>>>>
>>> People should restrict what packages they use from what repsitory they have
>>> enabled and/or exceptions. Having ovzkernel will not prevent additional
>>> kernel packages to be updated and potentially replacing the ovz kernel in
>>> grub. Especially when like in our case, we like to have the stock kernel
>>> available for disaster recovery, troubleshooting or vendor-support.
>>>
>>> So I don't see the purpose of renaming the ovz kernel package to ovzkernel.
>>> Users still need to check what kernel is in place and verify before
>>> rebooting. If anything, it gives a false sense of security or causes more
>>> confusing.
>>>
>>> Especially when documentation and forums refer to the following command to
>>> list the available kernels:
>>>
>>> rpm -q kernel
>>> or rpm -qa 'kernel-*'
>>>
>>> Proper standards should try to reduce the amount of 'expert' information.
>>> Needing to know that the openvz kernel is called ovzkernel is useless
>>> information by any means.
>>>
>> Dag, all,
>>
>> As you might be aware we have switched to name our kernel rpm just 'kernel' in
>> the latest devel release.
>>
>> Apparently, it broke the yum update procedure. New kernel is not recognized by
>> yum, even if it provides vzkernel. I have tried with a kernel package which
>> also 'Provides: ovzkernel = 2.6.18-ovz028test002' but that doesn't change the
>> situation. I will now try with 'Obsoletes: ovzkernel' but this solution is
>> rough since it will probably uninstall the previous kernel (depends on yum
>> version perhaps).
>>
>> I have also try "new install" scenario on my FC5 system, it works but with a
>> bad side effect:
>>
>> Dependencies Resolved
>>
>> ============================================================ =================
>> Package Arch Version Repository Size
>> ============================================================ =================
>> Installing:
>> vzctl i386 3.0.12-1 openvz 114 k
>> vzquota i386 3.0.9-1 openvz 47 k
>> Removing:
>> kernel i686 2.6.18-1.2200.fc5 installed 39 M
>> Installing for dependencies:
>> kernel i686 2.6.18-ovz028test002.1 openvz-kernel-devel
>> 11 M
>>
>> I.e. it tries to remove the latest FC5 kernel :-\ Too bad, I don't want
>> that...
>>
>> Perhaps somebody has a way to fix that?
>>
>
> Might this be because your system is configured to hold not more than X
> number of kernels ? I see no reason why a new kernel would cause an old
> kernel to be removed if there's no obsolete statement, except if there's a
> LIFO mechanism to push old kernels out.
>
> I'm interested to see the SPEC file and debug the problem.
The major problem here comes from the fact that OpenVZ kernels are older
than the distro ones.

Problem 1: clean install of kernel from rpm using yum:

[kir@kir kernel]$ sudo rpm -ihv kernel-2.6.18-ovz028test003.1.i686.rpm
Preparing... ###########################################
[100%]
package kernel-2.6.18-1.2200.fc5 (which is newer than
kernel-2.6.18-ovz028test003.1) is already installed

Possible fixes: remove all distro kernels (including the one you are
running on), or use --oldpackage option to rpm.

Still it will not solve the next problem.

Problem 2: yum update:

$ sudo yum update
...
============================================================ =================
Package Arch Version Repository Size
============================================================ =================
Installing:
kernel i686 2.6.18-1.2239.fc5
updates 15 M
Removing:
kernel i686 2.6.18-ovz028test003.1
installed 28 M
kernel i686 2.6.18-1.2200.fc5
installed 39 M
Removing for dependencies:
vzctl i386 3.0.12-1 installed 321 k
vzpkg noarch 2.7.0-18 installed 78 k
vzquota i386 3.0.9-1 installed 140 k
vztmpl-fedora-core-5 i386 2.0-2 installed 199 k
vztmpl-mandriva-2006 i386 1.0-1 installed 200 k

Possible fix: disable kernel packages from all the repos but OpenVZ one.
Hard to do since you can not do it in your own .repo file.

To tell the truth, I'm a bit lost at this point. Can anybody suggest
anything?
Previous Topic: iptables functionality
Next Topic: OpenVZ quota problem
Goto Forum:
  


Current Time: Sun Jul 28 08:19:34 GMT 2024

Total time taken to generate the page: 0.03599 seconds