Conversation
| s/redis-server.sock/redis.sock/g; \ | ||
| s/^client-output-buffer-limit pubsub [0-9]+mb [0-9]+mb [0-9]+/client-output-buffer-limit pubsub 0 0 0/; \ | ||
| s/^bind 127.0.0.1 ::1$/# bind 127.0.0.1 ::1/; \ | ||
| s/^protected-mode yes/protected-mode no/; \ |
There was a problem hiding this comment.
Redis protected mode only prevents the Redis server from responding to queries outside the loopback interfaces.
Docker network mode was changed from host to bridged. This requires to be able to connect from host IP to Redis docker IP.
| # Listen for connections on all ip addresses, including eth0, ipv4 and ipv6 lo | ||
| # | ||
| {% if SNMP_AGENT_ADDRESS_CONFIG %} | ||
| {% for (agentip, port, vrf) in SNMP_AGENT_ADDRESS_CONFIG %} |
There was a problem hiding this comment.
I am sorry, I wasn't aware of the other PR's for this feature.
The logic of address/port/vrf was moved to the docker create port and address forwarding. Since only user defined ports and addresses will be forwarded, this logic will no longer be relevant here
There was a problem hiding this comment.
I have updated the code to include the latest merged PR
There was a problem hiding this comment.
Could you explain "The logic of address/port/vrf was moved to the docker create port and address forwarding"?
There was a problem hiding this comment.
In the current implementation, snmpd has its configuration in snmpd.conf which defines which addresses and ports can be used for query, how and if vrf is being used, etc.
Removing snmp container from host network means that it is not exposed to any of these addresses by default,
What we did here was to use docker address:port forwarding as the method to implement the logic for it. When a user configures address and port to be used for snmp queries - this address:port tuple will be used when snmp docker is created, similar to a firewall. In what we offer here, the snmp demon inside the container will listen to all packets, and the docker networking logic (address:port forwarding) will forward only the relevant packets, as configured by user
| NET="host" | ||
| {%- if docker_container_name == "database" %} | ||
| NET="bridge" | ||
| PORT_MAP="-p 127.0.0.1:6379:6379" |
There was a problem hiding this comment.
If you mean multi-asic case. Its working. Each asic db docker has its own IP with mapped 6379 listening port and shared redis.sock socket file.
If there are more use cases, that may require different ports please elaborate.
There was a problem hiding this comment.
You may need to fetch the ports for all redis instances from conf files: "/var/run/redis/sonic-db/database_config.json".
With multi-DB feature, there will be multiple-namespace, and multiple instance per namespace. ref: https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_namespace_db_instances.md
| s/^# unixsocket/unixsocket/; \ | ||
| s/redis-server.sock/redis.sock/g; \ | ||
| s/^client-output-buffer-limit pubsub [0-9]+mb [0-9]+mb [0-9]+/client-output-buffer-limit pubsub 0 0 0/; \ | ||
| s/^bind 127.0.0.1 ::1$/# bind 127.0.0.1 ::1/; \ |
| fi | ||
| {%- if docker_container_name == "snmp" %} | ||
| # get snmp listening address and port list from redis | ||
| addr_port_values=$(python3 -c 'from swsscommon.swsscommon import ConfigDBConnector; cfg_db = ConfigDBConnector(); cfg_db.connect(wait_for_init=True, retry_on=True); [print(k[0] + "|" + k[1]) for k in cfg_db.get_keys("SNMP_AGENT_ADDRESS_CONFIG|*")]') |
There was a problem hiding this comment.
why is this logic moved here instead of doing in snmpd.conf.j2 file?
What is the value add we get?
This is done during docker create. If we are just restarting snmp server and there is a change in the SNMP_AGENT_ADDRESS_CONFIG in config_db, will the new change get picked up if we just restart running docker?
There was a problem hiding this comment.
This was moved here because port and address forwarding can only be done during docker create. What it means that in order to harden this container's network - each address/port change for this service will require docker removal and creation
There was a problem hiding this comment.
This PR will kill the feature of SNMP_AGENT_ADDRESS_CONFIG/port. Do you want to implement the same feature here or in another PR?
There was a problem hiding this comment.
I am not sure I understand your question. This PR and sonic-net/sonic-snmpagent#281 moves the logic of snmp networking management from the container to the host. The host will forward the relevant packets only (SNMP_AGENT_ADDRESS_CONFIG for example) and the container will take all packets sent to port 161
| NET="bridge" | ||
| DB_OPT=$DB_OPT" -v /var/run/redis$DEV:/var/run/redis:rw " | ||
| {%- elif docker_container_name == "snmp" %} | ||
| NET="bridge" |
There was a problem hiding this comment.
Checking best practice (https://docs.docker.com/network/network-tutorial-standalone/), default bridge network is not best choice for production. User-defined bridge networks is best choice for production. Can we use user-defined bridge network here?
There was a problem hiding this comment.
I agree, defining a user-defined bridge is the best case solution for this item.
Problem is - this FR wasn't scoped to define this user-bridge and therefor remained in the general bridge domain.
If such a bridge will be defined - then we can add it to the SNMP container and redis container (and any future container) as well.
734584b to
238a198
Compare
|
@qiluo-msft we addressed the comments and I adjusted the code to the recent merged snmp code. Can we proceed please? |
|
Please resolove conflict #Closed |
… container_net_host_remove
94258fa to
5296455
Compare
| NAMESPACE_COUNT=$NUM_ASIC | ||
| if [ -z $addr_port_values ]; then | ||
| if [ -z $NAMESPACE_COUNT ] || [ $NAMESPACE_COUNT -lt 2 ]; then | ||
| addr_port_values=$(python3 -c 'from swsscommon.swsscommon import ConfigDBConnector; cfg_db = ConfigDBConnector(); cfg_db.connect(wait_for_init=True, retry_on=True); [print(k[1].split("/")[0].lower() + "%" + k[0]) if len(k) == 2 and k[1].split('/')[0].lower().startswith("fe80") else print(k[1].split("/")[0].lower()) for k in cfg_db.get_keys("LOOPBACK_INTERFACE|*")+cfg_db.get_keys("MGMT_INTERFACE|*") if len(k) == 2]') |
There was a problem hiding this comment.
here currently only Loopback and Mgmt IP addresses are used.
There is SNMP_AGENT_ADDRESS_CONFIG table which can be configured with the IPs for snmpd to listen on.
This change does not include using that.
There was a problem hiding this comment.
@SuvarnaMeenakshi you either missed line 556 which addresses the specific SNMP_AGENT_ADDRESS_CONFIG table, or I miss something. I followed the logic that was found in snmpd.conf.j2 and translated it here
There was a problem hiding this comment.
This is throwing a syntax error.
python3 -c 'from swsscommon.swsscommon import ConfigDBConnector; cfg_db = ConfigDBConnector(); cfg_db.connect(wait_for_init=True, retry_on=True); [print(k[1].split("/")[0].lower() + "%" + k[0]) if len(k) == 2 and k[1].split('/')[0].lower().startswith("fe80") else print(k[1].split("/")[0].lower()) for k in cfg_db.get_keys("LOOPBACK_INTERFACE|")+cfg_db.get_keys("MGMT_INTERFACE|") if len(k) == 2]'
Why do we need the "fe80" check?
We can keep the fe80 condition in the snmpd.conf.j2 file?
|
Hi @ycoheNvidia, I wonder whether syslog generated inside bridge mode container can be written to host machine and update to remote syslog server? |
| {%- set LOOPBACK_IP = '' -%} | ||
| {%- endif -%} | ||
| command=/bin/bash -c "{ [[ -s /var/lib/{{ redis_inst }}/dump.rdb ]] || rm -f /var/lib/{{ redis_inst }}/dump.rdb; } && mkdir -p /var/lib/{{ redis_inst }} && exec /usr/bin/redis-server /etc/redis/redis.conf --bind {{ LOOPBACK_IP }} {{ redis_items['hostname'] }} --port {{ redis_items['port'] }} --unixsocket {{ redis_items['unix_socket_path'] }} --pidfile /var/run/redis/{{ redis_inst }}.pid --dir /var/lib/{{ redis_inst }}" | ||
| command=/bin/bash -c "{ [[ -s /var/lib/{{ redis_inst }}/dump.rdb ]] || rm -f /var/lib/{{ redis_inst }}/dump.rdb; } && mkdir -p /var/lib/{{ redis_inst }} && exec /usr/bin/redis-server /etc/redis/redis.conf --port {{ redis_items['port'] }} --unixsocket {{ redis_items['unix_socket_path'] }} --pidfile /var/run/redis/{{ redis_inst }}.pid --dir /var/lib/{{ redis_inst }}" |
There was a problem hiding this comment.
In SONiC Chassis, the SWSS container on the linecard connect to local database as well as the database_chassis instance on supervisor. This info is got from database_global.json. Will this be possible after this change
snippet from database_global.json on linecard
INSTANCES": {
"redis": {
"hostname": "127.0.0.1",
"port": 6379,
"unix_socket_path": "/var/run/redis/redis.sock",
"persistence_for_warm_boot": "yes"
},
"redis_chassis": {
"hostname": "redis_chassis.server",
"port": 6380,
"unix_socket_path": "/var/run/redis-chassis/redis_chassis.sock",
"persistence_for_warm_boot": "yes"
}
},
| NET="host" | ||
| {%- if docker_container_name == "database" %} | ||
| NET="bridge" | ||
| PORT_MAP="-p 127.0.0.1:6379:6379" |
| {%- else %} | ||
| /usr/local/bin/container stop $DOCKERNAME | ||
| {%- if docker_container_name == "snmp" %} | ||
| docker rm $DOCKERNAME |
There was a problem hiding this comment.
Docker container behavior requires that port forwarding is done during "docker run", and cannot be changed afterwards. Using port forwarding as a method of support net host remove will require removing docker stop, as it is called as part of service restart (docker stop + docker run).
An example for flow:
- snmp being configured -> snmp service established -> snmp docker created with "docker run" with relevant port forwarding arguments
- snmp configuration changes -> snmp service restart -> snmp old docker deleted + calling "docker run" with new port forwarding values
There was a problem hiding this comment.
If there is hot patches inside docker container, original behavior is that the patches will survive config reload or reboot. But this PR lose the capabilities.
There was a problem hiding this comment.
Are there real use-cases where a docker is being loaded with patches inside it?
There might also be some local files (such as temp config and such in every container), is this a real use-case?
There was a problem hiding this comment.
Yes, it is possible in production environment.
| NET="bridge" | ||
| PORT_MAP="-p 127.0.0.1:6379:6379" | ||
| {%- elif docker_container_name == "snmp" %} | ||
| NET="bridge" |
There was a problem hiding this comment.
I just tried image built by this PR yesterday, version: SONiC.master-15176.360116-6bb24c135. Looks like rsyslog inside snmp container cannot work well. I cannot find any syslog generated by snmp container (contains 'snmp#') in local host syslog file or our syslog server, and process containercfgd which is to dynamically generate rsyslog configuration file inside container doesn't startup. Not sure whether you have verified this, could you confirm that?
@Yarden-Z FYI
There was a problem hiding this comment.
@ycoheNvidia could check if change like this is needed. #4738
… container_net_host_remove
e52c538 to
f568e64
Compare
|
@ycoheNvidia 2 issues that I observed when using this diff with latest master branch image:
|
submodule change to support snmp container hardening: sonic-net/sonic-snmpagent#281
Why I did it
Net host removal for snmp and database as part of container hardening
How I did it
How to verify it
Modified snmp related templates to support net host removal:
Description for the changelog
snmp and database host net removal
A picture of a cute animal (not mandatory but encouraged)
,' `. \ /
| O ___/ |
^^^^^^^^^^^^~