Posted by j.slemmer on August 2, 2012 at 9:04am
2 followers
Jump to:
| Project: | Drupal Remote Dashboard |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hey Jurgen,
I have been increasing the sites monitored by DRD. On my D6 multisite I have issues on 4 sites;
- 3 Sites I can install and then get module status and info, but when I run "update domains" on that core they forget they were installed. So to get update info again, I have to reinstall those sites
- And one site I have this issue, it says it is installed, but the AES key is not working; http://screencast.com/t/epiobpwU
I do not have this issue on any other site in the same multisite
You got any ideas to debug this?
Comments
#1
#2
No idea to be honest. Your title states this is D7 related and in the body you're talking about D6. Which one is it in the end?
Maybe it is worth testing to delete that core from your list and then add it again to see if that already help.
If not, please turn on "Debugging" in the DRD settings and you should be seeing more detailed infos in your watchdog records, both on the DRD server and on the remotes domains. I hope something useful will come out of those logs so that we can get this nailed down.
#3
You are right, this was also D6. Not sure why I confused my self...
I have not found a solution yet and did not find more errors in the logs.
I suggest we check these when we meet at DrupalCon ok?
Much easier to supply details and checks..
Jons
#4
Good idea.
#5
Now included a lot more debugging info into the D6 version of drd_server. Please install that on your D6 core and push aes keys. We should then see quite a bit of info in the watchdog of the D6 core that's hosting the domain where we don't see the pushed keys.
#6
Fixed with the latest debug and patches.
ini_set(max_execution) time was causing the "aeskey" to not be set some how.
also the 3 other sites lost their known "installed" status after a key push, due to not being public (intranet or offline mode)
The permission needed was "access content" to anonymous users and on these sites that permission was nto granted.