Configuration & Administration

Expand all | Collapse all

Zope RoleManager Auth Redirect

  • 1.  Zope RoleManager Auth Redirect

    Posted 03-13-2020 05:13 PM
    Attempting to deploy a VMWare virtual appliance of Zenoss Community Edition, have been running 4.2.4 for a while now. 3 host deployment went fine and Zenoss is up and running.

    However I'm trying to enable LDAP authentication in Zenoss following directions from the wiki: http://wiki.zenoss.org/Enabling_LDAP_Authentication_in_Zenoss_Core_5

    Was able to install packages but got to the step where you Restrict Zenoss Access and ran into issue. When I navigate to Zope zport/manage then click on acl_users and attempt to click on roleManager I'm redirected to Zenoss login page even though I'm logged in as admin. Any of the links with cylinder next to them like groupManager, roleManager & userManager redirect to logon and admin or zenoss system accounts give an invalid login when giving the correct password. I thought I must have messed something up so deleted the Zenoss deployment and redeployed again without performing the LDAP install steps. In a fresh install if I go to /zport/manage acl_users still get this prompt to login when click on groupManager, roleManager & userManager

    Just to be sure I did run a zodbscan to check the Zope database which found no issues. Unsure of how to proceed and would appreciate any input on troubleshooting this. -Jarred


  • 2.  RE: Zope RoleManager Auth Redirect

    Posted 03-17-2020 02:01 PM
    This appears to be a known bug.  If you have access to JIRA (the Community version, you don't need to be a paying customer), then have a look at https://jira.zenoss.com/browse/ZEN-24700 . It suggests that version  Zenoss 5.1.5  is affected and that the fix is in 6.0 but I think you are implying you are at a 4.x version?

    Two workarounds are given.  The first one involves using zendmd to change dmd.allowManageAccess:

    • serviced service attach zope
    • su - zenoss
    • zendmd
    • dmd.allowManageAccess = True
    • commit()
    • exit zendmd
    • leave the zenoss user's shell
    • disconnect from the container
    • serviced service restart zope
    • then do the original repro steps
    • after ldap is setup, go through the above steps, but set:
    • dmd.allowManageAccess = False
    If you are pre-Zenoss 5 then you don't need any of the container stuff, just the zendmd bits (as the zenoss user) and restart zopectl.

    I already have LDAP configured in my 4.2.5 SUP 743 and I couldn't get any change using this zendmd trick.

    However, the same JIRA ticket points to some monkey patching that I am guessing is shipped with some Zenoss updates:

    su - zenoss
    edit /opt/zenoss/Products/ZenUtils/patches/pasmonkey.py
    comment out the line 'disable_pas_resources()' (line 532)
    save and quit

    My SUP 743 system does have this file and does have a disable_pas_resources() function (in my case at line 232, last line).  I took a copy of the file for safety and then commented out the line and restarted zopectl.  THIS WORKED.

    Repeated the process with zendmd and neither setting seemed to have any effect (just as before).

    I guess the presence of the disable_pas_resources() function and the line at which it occurs, will vary depending on your Zenoss version and patch level.

    Cheers,
    Jane


    ------------------------------
    Jane Curry
    Skills 1st United Kingdom
    jane.curry@skills-1st.co.uk
    ------------------------------



  • 3.  RE: Zope RoleManager Auth Redirect

    Posted 03-23-2020 01:31 PM
    Jane,

    Thanks for response. This is actually 6.1.2 community edition I'm trying to get LDAP working on, we have LDAP working fine in our old 4.2.4 environment but rolling out new Zenoss instance as OS running Zenoss 4.2.4 is end of support.

    I attempted to follow directions given by you/ticket even though this is for older version of Zenoss. I attempted to run zendmd and got errors after connecting to the container about unable to connect to localhost:8983/solr/.... Turns out SOLR service wasn't started (again I'm just going with defaults that came with the virtual appliance config so why did it not startup SOLR?). I manually started up SOLR in Control Center and it showed an error. I restarted the service and then it seemed to startup OK and Control Center Health Checks all showed good. Then zendmd command worked/launched. Commands to set allowManageAccess = True worked but Commit() returned several errors, pasted output below:

    (zenoss) [zenoss@609078ac3b18 ~]$ zendmd
    Welcome to the Zenoss dmd command shell!
    'dmd' is bound to the DataRoot. 'zhelp()' to get a list of commands.
    In [1]: dmd.allowManageAccess = True
    In [2]: commit()
    ---------------------------------------------------------------------------
    TypeError Traceback (most recent call last)
    <ipython-input-2-000b29768406> in <module>()
    ----> 1 commit()
    /opt/zenoss/Products/ZenModel/zendmd.py in commit()
    238 audit.audit('Shell.Script.Commit')
    239 from transaction import commit
    --> 240 commit()
    241
    242 def grepdir(obj, regex=""):
    /opt/zenoss/lib/python2.7/site-packages/transaction/_manager.pyc in commit(self)
    129 """ See ITransactionManager.
    130 """
    --> 131 return self.get().commit()
    132
    133 def abort(self):
    /opt/zenoss/lib/python2.7/site-packages/transaction/_transaction.pyc in commit(self)
    306 tb = None
    307 try:
    --> 308 t, v, tb = self._saveAndGetCommitishError()
    309 self._callAfterCommitHooks(status=False)
    310 reraise(t, v, tb)
    /opt/zenoss/lib/python2.7/site-packages/transaction/_transaction.pyc in _saveAndGetCommitishErr or(self)
    327 t, v, tb = sys.exc_info()
    328 # Record how we got into commit().
    --> 329 traceback.print_stack(sys._getframe(1), None, ft)
    330 # Append the stack entries from here down to the exception.
    331 traceback.print_tb(tb, None, ft)
    /usr/lib64/python2.7/traceback.pyc in print_stack(f, limit, file)
    267 except ZeroDivisionError:
    268 f = sys.exc_info()[2].tb_frame.f_back
    --> 269 print_list(extract_stack(f, limit), file)
    270
    271 def format_stack(f=None, limit=None):
    /usr/lib64/python2.7/traceback.pyc in print_list(extracted_list, file)
    23 ' File "%s", line %d, in %s' % (filename,lineno,name))
    24 if line:
    ---> 25 _print(file, ' %s' % line.strip())
    26
    27 def format_list(extracted_list):
    /usr/lib64/python2.7/traceback.pyc in _print(file, str, terminator)
    11
    12 def _print(file, str='', terminator='\n'):
    ---> 13 file.write(str+terminator)
    14
    15
    TypeError: 'unicode' does not have the buffer interface
    In [3]:

    The second option to edit /opt/zenoss/Products/ZenUtils/patches/pasmonkey.py didn't apply, the file ends at line 506 on my system and there is no 'disable_pas_resources()' line present in the config.

    Any other ideas? The fact that SOLR was not started has me concerned. Should all services under public endpoints be running under the Zenoss instance in Control Center? HMaster, opentsdb and second Zenoss.Core zproxy service are also not started (see screenshot). Should any of those three also be running?





    ------------------------------
    Jarred Rollins
    IT Security Engineer
    Principal Financial Group
    Des Moines IA
    ------------------------------