Detail: Make change in 95df86e1e030ab955ac09f145df37f3aef606c05 be specific
to VPC.
BUG-ID : NONE
Reviewed-by: Marcus Sorensen
Reported-by: Marcus Sorensen
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1351695701 -0600
Detail: Several virtual router configuration commands, such as iptables
commands, run slowly due to attempting to do a name lookup on the virtual
router's hostname and having to time out. This is seen in the agent logs when
a virtual router command is run, as "unable to resolve host r-410-VM" or
similar. This can make for very slow router configuration, especially as the
number of network rules grows. This change simply sets the router's name to
the localhost IP in /etc/hosts
BUG-ID : NONE
Reviewed-by: Marcus Sorensen
Reported-by: Marcus Sorensen
Signed-off-by: Marcus Sorensen <shadowsor@gmail.com> 1351659441 -0600
By default do not enable port 8080 in iptables-router. Since, the socat
server which serves the password is in an infinite loop, any incorrect
attempt is returned bad_request and passwd-srvr won't break.
When /etc/init.d/cloud-passwd-srvr is started:
- It finds and removes any old rules on port 8080, eth0
- It applies iptables rule that accepts only traffic from private cidr.
When cloud-passwd-srvr is stopped:
- It removes iptables rules on port 8080, eth0
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Also added license header for passwd_server_ip
Ported from:
commit 1072ec7ae36911ed794c182a1146025a0e969ea9
Author: Sheng Yang <sheng.yang@citrix.com>
Date: Wed Sep 12 11:15:33 2012 -0700
CS-16318: Update the fix with some tweak
1. The old fix run cloud-passwd-srvr twice because cloud-passwd-srvr is
still in the list of enabled_svcs
2. The lock should be applied on serve_password.sh, which controlled the
accessing to the password. Applied on the MASTER/BACKUP switch is useless, two
instance of serve_password.sh would still able to access the password file at
the same time.
3. Password service is a part of redundant router state transition process
now, so if the service failed to start, then the transition failed.
4. Restart password service should be put before restart dnsmasq, which
would sent out DHCP offer to the user vms. If user VMs got the DHCP offer first
but failed to get password, there would be an issue.
Reviewed-by: Anthony Xu
commit fa94da114099da357df7daa1aad3c327868393ca
Author: Jayapal Reddy <jayapalreddy.uradi@citrix.com>
Date: Wed Sep 12 17:57:03 2012 +0530
Bug:CS-16318 Starting password server on the both IPs in RRVM
Reviewed-by: Abhi
Conflicts:
patches/systemvm/debian/config/opt/cloud/bin/passwd_server
In order to make sure next time, booting process would use cloud-early-config's
setup, rather than networking scripts to bring up interfaces.
Reviewed-by: Kelven Yang
I can't see why we set eth0 to dhcp by default. It would result in eth0 want to
get a DHCP address from outside. We should always assign ip through
cloud-early-config for it.
But one point is, the priority of cloud-early-config and networking script is
the same. So even networking got some ip from outside, cloud-early-config
should able to override it(if cloud-early-config runs after networking) or
networking script won't get dhcp (if cloud-early-config runs before networking),
so I am not quite understand why router would get DHCP address in fact. Maybe
there are other issues.
The following are summary of changes:
1) when network.disable.rpfilter is set to true, then rp_filter will be disadbled(set to 0) on all the public interfaces and also default setting of the system.
2) when network.disable.rpfilter is set to false, then rp_filter will be enabled(set to 1) on all the public interfaces and also default setting of the system.
3) here public public interface means , eth2 ... ethN. default setting means (/proc/sys/net/ipv4/conf/default/rp_filter).
4) Default setting change will have impact on non-public interface. Due to these, rp_filter is always enabled on Non-public interfaces(eth0,eth1 and lo).
5) when a new public interface is created, new interface will take rp_filter value from the default setting.
The following are summary of changes:
1) when network.disable.rpfilter is set to true, then rp_filter will be disadbled(set to 0) on all the public interfaces and also default setting of the system.
2) when network.disable.rpfilter is set to false, then rp_filter will be enabled(set to 1) on all the public interfaces and also default setting of the system.
2) here public public interface means , eth2 ... ethN. default setting means (/proc/sys/net/ipv4/conf/default/rp_filter).
3) Default setting change will have impact on non-public interface.if there is no specific setting for other interfaces in /etc/sysctl.conf or otherexplict setting , they will follow this default settings. currently non-public interface like eth0 ,eth1 does not have any specific setting in sysctl.conf, due to this there rp_filters will be changed when ever network.disable.rpfilter setting is changed.
4) default setting is required to changes beacuse when a new public interface is created, new interface will take rp_filter value from the default setting.
Added global config to enable/disable rp_filter for domR.
previous commit: d966906374d4a0cb8fa57326a1f7625c871f64fd
Test Case-1 :
1) Set network.disable.rpfilter global config to true
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 0 , and rest other interfaces should have value of 1
Test Case-2 :
1) set network.disable.rpfilter global config to false
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 1 , and rest other interfaces should also have value of 1
