Home » General » Support » *SOLVED* ipt_owner within a VE
*SOLVED* ipt_owner within a VE [message #14156] |
Fri, 15 June 2007 21:46 |
nksupport
Messages: 16 Registered: June 2007
|
Junior Member |
|
|
Trying to get the subject working. Works for the host OS, but vzctl enter and even vzlist say
Warning: Unknown iptable module: ipt_owner, skipped
I believe everything is configured OK:
grep owner /etc/vz/vz.conf
IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_owner"
lsmod | grep owner
ipt_owner 6400 0
ip_tables 35096 12 ipt_owner,iptable_nat,ipt_length,ipt_ttl,ipt_tcpmss,ipt_TCPMSS,iptable_mangle,iptable_filter,ipt_multiport,ipt_limit,ipt_tos,ipt_REJECT
Host OS is RHEL 4 update 5 x86_64
kernel 2.6.9-023stab044.4-smp, also tried development and 2.6.18 with same effect
vzctl 3.0.16.1, already tried recompiling the source RPM running under the specified kernel with no effect.
Googling did not give me the exact answer if the feature is working in OpenVZ. Is it so? Does anybody have an example of a working setup?
UPDATE: now i have a working installation as well )
"It's the power cord", I say
[Updated on: Wed, 20 June 2007 06:34] by Moderator Report message to a moderator
|
|
|
Re: ipt_owner within a VE [message #14171 is a reply to message #14156] |
Sun, 17 June 2007 08:33 |
|
curx
Messages: 739 Registered: February 2006 Location: Nürnberg, Germany
|
Senior Member |
|
|
Hi,
iptables "OWNER" module isn't virtualized,
only listed iptables modules can be used in VE context:
(see man-page of vzctl)
iptable_filter,iptable_mangle, ipt_limit, ipt_multiport,
ipt_tos, ipt_TOS,ipt_REJECT, ipt_TCPMSS, ipt_tcpmss,
ipt_ttl, ipt_LOG, ipt_length, ip_conntrack, ip_conntrack_ftp,
ip_conntrack_irc, ipt_conntrack, ipt_state, ipt_helper,
iptable_nat, ip_nat_ftp, ip_nat_irc, ipt_REDIRECT xt_mac.
|
|
|
|
|
Re: ipt_owner within a VE [message #14222 is a reply to message #14219] |
Tue, 19 June 2007 18:46 |
nksupport
Messages: 16 Registered: June 2007
|
Junior Member |
|
|
root@x2 ~ # lsmod | grep own
ipt_owner 6400 0
ip_tables 35096 12 ipt_owner,iptable_nat,ipt_length,ipt_ttl,ipt_tcpmss,ipt_TCPMSS,iptable_mangle,iptable_filter,ipt_multiport,ipt_limit,ipt_tos,ipt_REJECT
root@x2 ~ # vzctl enter 103
Warning: Unknown iptable module: ipt_owner, skipped
entered into VE 103
2.6.9-023stab044.4-smp
18:37:34 up 3 days, 21:24, 0 users, load average: 0.26, 0.23, 0.14
LANG=C
root@p4 / # iptables -I OUTPUT -m owner --uid-owner=110 -j ACCEPT
iptables: No chain/target/match by that name
/lib/iptables/libipt_owner.so exists within the VE.
"It's the power cord", I say
|
|
|
|
|
Re: *SOLVED* ipt_owner within a VE [message #14692 is a reply to message #14156] |
Fri, 06 July 2007 09:30 |
GameOver
Messages: 4 Registered: November 2005
|
Junior Member |
|
|
Hi nightkid,
What did you do to enable iptables owner module? In the patch for kernel 2.6.18, I don't see anything for ipt_owner. Did you just enable it in kernel config and recompile? Also, do you any problem with your server after enabling ipt_owner?
To OpenVZ developers: could you virtualize ipt_owner and enable it by default in stable kernel? We need this module to restrict outgoing connections to specific UIDs/GIDs to help prevent our users from bypassing MTA to connect directly to remote mail server to send spam. I think many people especially those operating hosting servers will need it too.
Many thanks,
|
|
|
Re: *SOLVED* ipt_owner within a VE [message #15272 is a reply to message #14692] |
Wed, 25 July 2007 16:56 |
nksupport
Messages: 16 Registered: June 2007
|
Junior Member |
|
|
Yes, I simply enabled it in the kernel config and rebuilt the kernel SRPM. There was one problem, though: an attempt to unload the iptables modules from the node's kernel causes a panic - I ignored it, as there is no need to unload those. I did not apply patches.
"It's the power cord", I say
[Updated on: Wed, 25 July 2007 16:57] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Thu Oct 17 13:58:15 GMT 2024
Total time taken to generate the page: 0.05570 seconds
|