Forum Discussion

KaiDuerkop's avatar
KaiDuerkop
Icon for Nimbostratus rankNimbostratus
Nov 29, 2016

Users are synchronized automatically? (autosync deactivated)

Hey, we have a BIG-IP 12.1.1 Cluster and after 10 seconds I've created a user on the active BIG-IP, this system synchronize the User automatically. (autosync is disabled)

What happened there? The Clusterstatus is on "Changes Pending" and the active BIG-IP has a "more recent configuration" warning.

Active BIG-IP

mcpd[6544]: 01070417:5: AUDIT - client tmsh, tmsh-pid-23777, user fib0rkd - transaction 47414394-3 - object 0 - create { userdb_entry { userdb_entry_name "testuser" userdb_entry_shell "bash" } } [Status=Command OK]

mcpd[6544]: 01070417:5: AUDIT - client tmsh, tmsh-pid-23777, user fib0rkd - transaction 47414394-2 - object 0 - create { user_role_partition { user_role_partition_partition "[All]" user_role_partition_user "testuser" user_role_partition_role 0 } } [Status=Command OK]

tmsh[23777]: 01420002:5: AUDIT - pid=23777 user=fib0rkd folder=/Common module=(tmos) status=[Command OK] cmd_data=create auth user testuser partition-access add { all-partitions { role admin } } shell bash

mcpd[6544]: 01070417:5: AUDIT - client Unknown, user admin - transaction 47414401-2 - object 0 - modify { user_role_partition { user_role_partition_user "testuser" user_role_partition_partition "[All]" user_role_partition_role 700 } } [Status=Command OK]

mcpd[6544]: 01070417:5: AUDIT - client Unknown, user admin - transaction 47414411-2 - object 0 - modify { user_role_partition { user_role_partition_user "testuser" user_role_partition_partition "[All]" user_role_partition_role 700 } } [Status=Command OK]

mcpd[6544]: 01070417:5: AUDIT - client Unknown, user admin - transaction 47414438-2 - object 0 - modify { user_role_partition { user_role_partition_user "testuser" user_role_partition_partition "[All]" user_role_partition_role 700 } } [Status=Command OK]

Standby BIG-IP

mcpd[6018]: 01070417:5: AUDIT - client Unknown, user admin - transaction 6361419-2 - object 0 - create { userdb_entry { userdb_entry_name "testuser" userdb_entry_description "testuser" userdb_entry_passwd "***" userdb_entry_is_crypted 1 userdb_entry_gecos "testuser" } } [Status=Command OK]

mcpd[6018]: 01070417:5: AUDIT - client Unknown, user admin - transaction 6361419-3 - object 0 - create { user_role_partition { user_role_partition_user "testuser" user_role_partition_partition "[All]" user_role_partition_role 700 } } [Status=Command OK]

mcpd[6018]: 01070417:5: AUDIT - client Unknown, user admin - transaction 6361461-2 - object 0 - modify { user_role_partition { user_role_partition_user "testuser" user_role_partition_partition "[All]" user_role_partition_role 0 } } [Status=Command OK]

5 Replies

  • The default device-group "device_trust_group" could be to blame? I did not check the SOL but I assume in v12.x it has auto-sync enabled by default, and the data-group itself will automatically synchronize primitive parts of configuration such as native user conf (/config/bigip_user.conf)

    Check this with

     tmsh list cm device-group device_trust_group
     tmsh show cm sync-status
    

    You shouldn't worry about that, as long as other non-primitive parts are not synced without your consent (config permitting that). You can verify that by creating a node or pool - if this gets synced automatically then you have a problem.

    • KaiDuerkop's avatar
      KaiDuerkop
      Icon for Nimbostratus rankNimbostratus

      We dont want that users are synchronized automatically. We use scripts to create user (on the active BIG-IP) and after that it tries to synchronize the cluster.

      This runs into a problem because the user is synchronized and the backup BIG-IP has an newer config...

      It is not possible to set the "overwrite" flag via tmsh sync command. (?)

      Even the auto-sync disable command does not work for the device_trust_group 😞

      modify cm device-group device_trust_group auto-sync disabled
      
      list cm device-group device_trust_group
      
      cm device-group device_trust_group {
          auto-sync enabled
          devices {
              device1 { }
              device2 { }
          }
          network-failover disabled
      }
      

      ~~~

  • The default device-group "device_trust_group" could be to blame? I did not check the SOL but I assume in v12.x it has auto-sync enabled by default, and the data-group itself will automatically synchronize primitive parts of configuration such as native user conf (/config/bigip_user.conf)

    Check this with

     tmsh list cm device-group device_trust_group
     tmsh show cm sync-status
    

    You shouldn't worry about that, as long as other non-primitive parts are not synced without your consent (config permitting that). You can verify that by creating a node or pool - if this gets synced automatically then you have a problem.

    • KaiDuerkop's avatar
      KaiDuerkop
      Icon for Nimbostratus rankNimbostratus

      We dont want that users are synchronized automatically. We use scripts to create user (on the active BIG-IP) and after that it tries to synchronize the cluster.

      This runs into a problem because the user is synchronized and the backup BIG-IP has an newer config...

      It is not possible to set the "overwrite" flag via tmsh sync command. (?)

      Even the auto-sync disable command does not work for the device_trust_group 😞

      modify cm device-group device_trust_group auto-sync disabled
      
      list cm device-group device_trust_group
      
      cm device-group device_trust_group {
          auto-sync enabled
          devices {
              device1 { }
              device2 { }
          }
          network-failover disabled
      }
      

      ~~~

  • The BIG-IP system uses a REST framework to synchronize some configuration elements separately from synchronization performed by the ConfigSync process. When this issue occurs, the user configuration is synchronized to the peer devices, even when Automatic Sync is disabled in the device group settings. The BIG-IP system interprets this as a manual change being performed on the devices and triggers a change conflict.

     

    https://support.f5.com/csp/article/K08062851

     

    Fix is introduced in 12.1.3.6 point release onward.