Posts by bkeadle

    Well LA DEE DAH! Resolved! How any of it worked and just not the geUserList I don't get.

    Having started the omv-engined in debug mode:

    monit stop omv-engined
    omv-engined -df

    And then referencing this guide (for the umpteenth time), when I restarted the winbind service

    service winbindrestart

    , a saw a bunch of LDAP errors scroll by in the omv-engined debug screen, referencing unable to talk to my AD server via LDAPS. I then edited the associated files and restarted winbind again:

    vi /etc/libnss-ldap.conf
    cat /etc/pam_ldap.conf
    vi /etc/pam_ldap.conf
    service winbind restart

    And voila - no errors, and the getUserList returned my AD users! Woo hoo! :thumbsup:

    One minor(?) observation, however: in my user list, the email address for all my users are blank - though I know my users have email addresses associated (especially because we are using Office365 for our email with AD integration). Is that something I will need to concern myself?

    As for the timeouts, wouldn't that be ignored by specifying a smaller limit using:

    /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":25,"sortfield":"name","sortdir":"ASC"}'

    the other commands to return the user list (410 total) comes back almost immediately, so it would seem that latency isn't the issue. Since the getGroupList returns almost instantly, I'm wondering if the getUserList isn't returning the correct information for users, and so it timesout looking for some specific attribute that isn't getting returned? Any idea how to test that? What does a getUserList look like?

    Thanks. Yeah, I saw that about the 3,000 users, and I made those timeout changes. Still, I have much fewer objects (410). It's just so puzzling that all the *other* commands work correctly (wbinfo -u/-g, getent passwd/group, omv-rpc "UserMgmt" "getGroupList"), only omv-rpc "UserMgmt" "getUserList" fails. :/

    /usr/sbin/omv-rpc "UserMgmt" "getGroupList" '{"start":0,"limit":25,"sortfield":"name","sortdir":"ASC"}'

    returns a list

    /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":25,"sortfield":"name","sortdir":"ASC"}'

    times out with the error. Seems like this is a major clue, pointing to either or whatever it's calling.

    Quick question: when trying changes to /usr/share/openmediavault/engined/rpc for troubleshooting, do I need to restart anything to effect the change? Or is it effectively immediately?

    Also, is there some sort of an array limit that's making the function fail? I have 410 users that come back in 'wbinfo -u'

    Yes, I've seen those posts and done those settings.

    I'm running againsts Windows Server 2012, and OMV v2.2 That was the "latest", but I have seen references to v3. Is that something I can do an in-place upgrade to? I've got quite a bit of effort invested in this 2.2 installation.

    Now I'm wondering if the issue is tied to this some how:

    since the getGroupList function is returning correctly, I compared it to the getUserList function. It looks very similar, just curious why getting groups list from AD works but not users list.

    Digging a bit deeper, I found somewhere about running:

    omv-engined -d -f

    so that I can see request output. Having done that, and selecting the Group item, which returns a list, I see this output:

    Executing RPC (service=UserMgmt, method=getGroupList, params={"start":0,"limit":25,"sortfield":"name","sortdir":"ASC"}, context={"username":"admin","role":1}) ...
    RPC response (service=UserMgmt, method=getGroupList): {"response":{"total":324,"data":[{"name":"-acad","gid":16777455,"members":["mgrabowski","scvetan"],"system":false},...
    SIGCHLD received ...
    Child (pid=7237) terminated with exit code 0

    But when I click on the User item, I see this output:

    Executing RPC (service=ShareMgmt, method=enumerateSharedFolders, params={"start":0,"limit":25,"sortfield":null,"sortdir":null}, context={"username":"admin","role":1}) ...
    RPC response (service=ShareMgmt, method=enumerateSharedFolders): {"response":[],"error":null}
    SIGCHLD received ...
    Child (pid=9371) terminated with exit code 0

    Which to my untrained eye, doesn't look like it's running the command I've been using to test:

    /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":null,"sortfield":null,"sortdir":null}'

    Which this command returns the error output shown above in the first post.

    That's a cool trick! Perfect. Thank you.

    ryecoaaron: you are single-handedly making this solution viable (due to the sense of "support") for your prompt and helpful contributions via these forums - THANK YOU.

    It would seem the magic bullet is going to be in /var/www/openmediavault/js/omv/data/proxy/Rpc.js somewhere. Futzing with it will either generate the none/nobody as above, or, a timeout with this output:

    oot@omv-pd:~# /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":null,"sortfield":null,"sortdir":null}'
    {"response":null,"error":{"code":7003,"message":"Failed to read from socket: Resource temporarily unavailable","trace":"exception 'OMVException' with message 'Failed to read from socket: Resource temporarily unavailable' in \/usr\/share\/php\/openmediavault\/\nStack trace:\n#0 \/usr\/sbin\/omv-rpc(107): OMVRpc::exec('UserMgmt', 'getUserList', Array, Array, 2)\n#1 {main}"}}

    This thread and this entry lead me to Rpc.js file. This is the current contents:

    Note the hard-coded entry of 60000 instead of the OMV.HTTPREQUEST_TIMEOUT variable

    I've spent countless hours trying to get LDAP/AD integration working. I got really close, with being able to get the Groups in AD to list in the OMV WebGUI, but the User would throw a communication error. A common/known issue. I've learned that we need to see

    /usr/sbin/omv-rpc "UserMgmt" "getUserList" '{"start":0,"limit":null,"sortfield":null,"sortdir":null}'

    to work. I was having an issue with that command timing out. This thread was helpful, but somewhere along the way, now the omv-rpc command just returns "nobody" on both User and Group pages. However, all these commands return AD information without issue:

    wbinfo -u
    wbinfo -i {someuser}
    wbinfo -g
    getent passwd
    getent group

    so it seems my LDAP/AD integration is healthy, but just not the omv-rpc command to return that information for the WebGUI. I'm *so* close! Please help!

    If there isn't a way to incorporate the megaraid-status, is there a way to add a link to the OMV interface, that would run a defined command and show the output? I see some actions will show a command output.

    To my pleasant surprise, especially since I don't really know what I'm doing, I was successful in installing megaraid-status from the debian sources refrenced above, and actually got identifiable output!:

    oooo...and megactl:

    Goodie! That's the sort of disk information I'm looking for. But now, what to do with it? Is there any sort of OMV plugin that will show this status or provide any sort of alerting?

    As for the megacli reference, seems to have dropped off - what's the conclusion to that thread? Is there a deb package for megacli? I did find this, but I'm unclear how to retrieve and install or if this is what I should be attempting.

    Thanks for the link. I'll check it out.

    Hmm...each of the logical drives you see in the print screen are RAID5 HW RAID with a hot spare. So "losing a drive" shouldn't effect wouldn't even know about it. I'm not familiar with unionfilesystem...that's basically what I'm wanting to accomplish with LVM is to be able to pool all those "logical drives".

    It used to run Lefthand SANiQ, but since upgrading the 250GB disks to 2TB drives, it couldn't handle it, so I decided to go with OMV for the OS to make use of this otherwise great piece of hardware (that's EOL)

    Along these lines (perhaps deserves a separate thread?), my only concern is not seeing the condition of the RAID and physical disks. These are MegaRAID controllers. Is there a way to know the status of the disks and the HW RAID? The S.M.A.R.T. interface is just showing the logical volumes provided by the MegaRAID:

    I figure it's best to have the HW RAID, and use OMV LVM to combine all the logical disks into one large datastore. Yes?