[ovirt-users] host upgrade from ovirt manager and custom iptables rules

Fri Jun 20 13:07:15 UTC 2014

Dne 20.6.2014 0:19, Alon Bar-Lev napsal(a):
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com> To: "Jiří Sléžka"
>> <jiri.slezka at slu.cz>, "Alon Bar-Lev" <abarlev at redhat.com> Cc:
>> users at ovirt.org Sent: Friday, June 20, 2014 1:12:58 AM Subject: Re:
>> [ovirt-users] host upgrade from ovirt manager and custom iptables
>> rules
>>
>>
>>
>> ----- Original Message -----
>>> From: "Jiří Sléžka" <jiri.slezka at slu.cz> To: "Moti Asayag"
>>> <masayag at redhat.com> Cc: users at ovirt.org Sent: Thursday, June 19,
>>> 2014 3:25:49 PM Subject: Re: [ovirt-users] host upgrade from
>>> ovirt manager and custom iptables rules
>>>
>>>> ----- Original Message -----
>>>>> From: "Jiří Sléžka" <jiri.slezka at slu.cz> To: users at ovirt.org
>>>>> Sent: Wednesday, June 18, 2014 8:12:09 PM Subject:
>>>>> [ovirt-users] host upgrade from ovirt manager and custom
>>>>> iptables rules
>>>>>
>>>>> Hello all,
>>>>>
>>>>> is there any way to make custom iptables rules persistent
>>>>> during host upgrade? I have for example zabbix agents
>>>>> installed on all hosts and thus iptables rule allowing
>>>>> connections from our zabbix server. Sadly I have to manually
>>>>> restore iptables backup after host upgrade (initiated from
>>>>> oVirt manager).
>>>>>
>>>>
>>>> This should be achievable by defining the iptables rules you
>>>> wish to use when [re]installing using the engine-config tool:
>>>
>>> thanks a lot for reply
>>>
>>>> 1. Check the existing iptables rules: sudo engine-config -g
>>>> IPTablesConfig
>>>
>>> this displays whole iptables template. Interesting thing is that
>>> there is a variable @CUSTOM_RULES at . Maybe custom rules could be
>>> defined this way?
>>>
>>
>> Adding Alon to reply on @CUSTOM_RULES@
>
> These are to be replaced with gluster specific or virt specific or
> both, see IPTablesConfigForVirt, IPTablesConfigForGluster.

I didn't find this variables in engine-config -a (oVirt 3.4.2-1.el6) but 
never mind

>
> I must note that there is no real support for manual modification of
> the iptables rules, as once you change it, you do not enjoy future
> product updates, such as upcoming kdump fence listener daemon.
>
> However, moti, we can add another vdc config for user defined rules,
> it should be sufficient in most cases.
>
>>
>>>>
>>>> 2. Define the desired iptables: sudo engine-config -s
>>>> IPTablesConfig="Your rules"
>>>
>>> I entered...
>>>
>>> engine-config -s IPTablesConfig="-A INPUT -p tcp -m state --state
>>> NEW -m tcp -s xx.xx.xx.xx --dport 10050 -j ACCEPT"
>>>
>>> ...and it looks like this overwrite entire IPTablesConfig
>>> template...
>>>
>>>> 3. Verify the changes sudo engine-config -g IPTablesConfig
>>>
>>> ...because this displays only just my one line above.
>>>
>>> I have copy of default template but I have no idea how to set
>>> this variable with multi line text. I tried inserting \n but it
>>> is not converted to newlines. Any ideas?
>>
>> to me i worked by pasting the file content in the command line:
>> engine-config -s IPTablesConfig=" <paste multi-line content>"

this didn't work for me but this workaround did :-)

IPRULES=$( cat /root/archive/iptables_default.txt )
engine-config -s IPTablesConfig="$IPRULES"

also ovirt-engine has to be restarted to changes take effect

btw. before I created iptables_default.txt with added custom line 
(before @CUSTOM_RULES@)

...
# zabbix
-A INPUT -p tcp -m state --state NEW -m tcp -s 193.84.206.99 --dport 
10050 -j ACCEPT

@CUSTOM_RULES@
...

now host's iptables are populated with this modified template upon 
upgrade. Agree, this is just ugly workaround. I am looking forward to 
version 3.6 as mentioned in this RFE 
https://bugzilla.redhat.com/show_bug.cgi?id=1111513

Thanks once more!

Jiri

>>
>>>
>>> Btw. these variables are stored in database?
>>
>> Yes, in vdc_options table:
>>
>> select * from vdc_options where option_name = 'IPTablesConfig';
>>
>>>
>>>
>>> Thanks in advance,
>>>
>>> Jiri
>>>
>>>
>>>
>>>>
>>>> 4. Restart the engine for changes to take effect
>>>>
>>>> 5. Reinstall the host and verify the iptables rule.
>>>>
>>>>> And another question I have always wanted to ask... It looks
>>>>> like host upgrade is upgrading just vdsm components and no
>>>>> others virtualization stuff
>>>>>
>>>>> this was updatet after clicking to "host upgrade"
>>>>>
>>>>> Jun 18 18:21:38 Updated: iproute-2.6.32-32.el6_5.x86_64 Jun
>>>>> 18 18:21:59 Installed:
>>>>> vdsm-python-zombiereaper-4.14.7-3.el6ev.noarch Jun 18
>>>>> 18:21:59 Updated: vdsm-python-4.14.7-3.el6ev.x86_64 Jun 18
>>>>> 18:21:59 Updated: vdsm-xmlrpc-4.14.7-3.el6ev.noarch Jun 18
>>>>> 18:21:59 Updated: vdsm-cli-4.14.7-3.el6ev.noarch Jun 18
>>>>> 18:22:26 Updated: vdsm-4.14.7-3.el6ev.x86_64 Jun 18 18:22:27
>>>>> Updated:
>>>>> 2:qemu-kvm-rhev-tools-0.12.1.2-2.415.el6_5.10.x86_64
>>>>>
>>>>> and after that I run yum update and updated this components
>>>>> (honestly this one was rhev host but ovirt behave the same)
>>>>>
>>>>> Jun 18 18:26:59 Updated:
>>>>> selinux-policy-3.7.19-231.el6_5.3.noarch Jun 18 18:27:03
>>>>> Updated: tzdata-2014d-1.el6.noarch Jun 18 18:27:10 Updated:
>>>>> glibc-2.12-1.132.el6_5.2.x86_64 Jun 18 18:27:22 Updated:
>>>>> glibc-common-2.12-1.132.el6_5.2.x86_64 Jun 18 18:27:22
>>>>> Updated: audit-libs-2.2-4.el6_5.x86_64 Jun 18 18:27:22
>>>>> Updated: libxml2-2.7.6-14.el6_5.1.x86_64 Jun 18 18:27:22
>>>>> Updated: libcurl-7.19.7-37.el6_5.3.x86_64 Jun 18 18:27:23
>>>>> Updated: 2:qemu-img-rhev-0.12.1.2-2.415.el6_5.10.x86_64 Jun
>>>>> 18 18:27:23 Updated: libtasn1-2.3-6.el6_5.x86_64 Jun 18
>>>>> 18:27:23 Updated: gnutls-2.8.5-14.el6_5.x86_64 Jun 18
>>>>> 18:27:25 Updated: openssl-1.0.1e-16.el6_5.14.x86_64 Jun 18
>>>>> 18:27:25 Updated: spice-server-0.12.4-6.el6_5.2.x86_64 Jun 18
>>>>> 18:27:25 Updated: gnutls-utils-2.8.5-14.el6_5.x86_64 Jun 18
>>>>> 18:27:25 Updated: pm-utils-1.2.5-10.el6_5.1.x86_64 Jun 18
>>>>> 18:27:28 Updated: libvirt-client-0.10.2-29.el6_5.9.x86_64 Jun
>>>>> 18 18:27:30 Updated: libvirt-0.10.2-29.el6_5.9.x86_64 Jun 18
>>>>> 18:27:30 Updated: libvirt-python-0.10.2-29.el6_5.9.x86_64 Jun
>>>>> 18 18:27:30 Updated: mom-0.4.0-1.el6ev.noarch Jun 18 18:27:30
>>>>> Updated: libvirt-lock-sanlock-0.10.2-29.el6_5.9.x86_64 Jun 18
>>>>> 18:27:32 Updated:
>>>>> 2:qemu-kvm-rhev-0.12.1.2-2.415.el6_5.10.x86_64 Jun 18
>>>>> 18:27:32 Updated: python-rhsm-1.9.7-1.el6_5.x86_64 Jun 18
>>>>> 18:27:32 Updated: curl-7.19.7-37.el6_5.3.x86_64 Jun 18
>>>>> 18:27:33 Updated: libxml2-python-2.7.6-14.el6_5.1.x86_64 Jun
>>>>> 18 18:27:33 Updated: audit-libs-python-2.2-4.el6_5.x86_64 Jun
>>>>> 18 18:27:33 Updated: audit-2.2-4.el6_5.x86_64 Jun 18 18:27:33
>>>>> Updated: mdadm-3.2.6-7.el6_5.2.x86_64 Jun 18 18:27:33
>>>>> Updated: python-cpopen-1.3-2.el6_5.x86_64 Jun 18 18:28:30
>>>>> Updated: selinux-policy-targeted-3.7.19-231.el6_5.3.noarch
>>>>> Jun 18 18:28:30 Updated:
>>>>> python-pthreading-0.1.3-1.el6ev.noarch
>>>>>
>>>>>
>>>>> I believe qemu-img-rhev, spice-server, libvirt, mom,... are
>>>>> important components too. Should not be upgraded as well?
>>>>>
>>>>>
>>>>> Thanks for clarification,
>>>>>
>>>>> Jiri
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ Users mailing
>>>>> list Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>
>>>
>> _______________________________________________ Users mailing list
>> Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jiri_slezka.vcf
Type: text/x-vcard
Size: 598 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140620/b38af319/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3243 bytes
Desc: Elektronicky podpis S/MIME
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140620/b38af319/attachment-0001.p7s>