Moodle
  1. Moodle
  2. MDL-9420

Apparently broken "networking" feature in 1.8

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Duplicate
    • Affects Version/s: 1.8
    • Fix Version/s: 1.8.4, 1.9
    • Component/s: MNet
    • Labels:
      None
    • Environment:
    • Database:
      MySQL
    • URL:
      N/A
    • Affected Branches:
      MOODLE_18_STABLE
    • Fixed Branches:
      MOODLE_18_STABLE, MOODLE_19_STABLE

      Description

      I have two moodle installs on the same webserver. One in /moodleone/ and one in /peer/. Networking is setup per the instructions found at http://docs.moodle.org/en/Moodle_Network - which seems pretty straightforward. However, it hangs up in the Setup->2->6 (to reference the docs). When (using a whole separate web browser), I log in as a user, I can see the remote host in the Networking box. However, when I click it, I get the following error:

      RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:

      1:Payload not encrypted

      This error is from mnet/xmlrpc/client.php down near line 250. I have also managed to get one other error message out of it (haven't yet tracked down where it came from):

      RPC auth/mnet/user_authorise:SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:func(144):reason(134)ERROR 60:

      60:SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:func(144):reason(134)

      Any help would be greatly appreciated.

        Gliffy Diagrams

          Activity

          Hide
          Martín Langhoff added a comment -

          Hi Adam,

          Really interesting. When the SSL cert is self-signed we should be falling back to not requiring that. We tested this early on, but it seems it's not working any more.

          Show
          Martín Langhoff added a comment - Hi Adam, Really interesting. When the SSL cert is self-signed we should be falling back to not requiring that. We tested this early on, but it seems it's not working any more.
          Hide
          Adam Lambert added a comment -

          So, the webserver cert is involved in this process somehow? I was under the impression that moodle was doing it's own self-signed scheme (the cert's visible under admin->networking->peers are NOT the same cert as the server uses... ??

          Show
          Adam Lambert added a comment - So, the webserver cert is involved in this process somehow? I was under the impression that moodle was doing it's own self-signed scheme (the cert's visible under admin->networking->peers are NOT the same cert as the server uses... ??
          Hide
          Martín Langhoff added a comment -

          You are right - moodle is doing its own encryption, but as you are using https, it's also https encrypted. There's an optimisation we could do here in "just" signing but not encrypting if we know the transport is https. Tag that one for 1.9

          The curl library that we use to make the xml-rpc calls has an option to accept self-signed certs, somehow the code is getting tangled there. It was working.

          Donal - what do you think? My guess is that we need to relax CURLOPT_SSL_VERIFYHOST and then check the results with CURLINFO_SSL_VERIFYRESULT to apply whatever level of strictness we want - probably around mnet/xmlrpc/client.php . I can't find the code that did it, but I do remember seeing you test it with a self-signed cert early on.

          Show
          Martín Langhoff added a comment - You are right - moodle is doing its own encryption, but as you are using https, it's also https encrypted. There's an optimisation we could do here in "just" signing but not encrypting if we know the transport is https. Tag that one for 1.9 The curl library that we use to make the xml-rpc calls has an option to accept self-signed certs, somehow the code is getting tangled there. It was working. Donal - what do you think? My guess is that we need to relax CURLOPT_SSL_VERIFYHOST and then check the results with CURLINFO_SSL_VERIFYRESULT to apply whatever level of strictness we want - probably around mnet/xmlrpc/client.php . I can't find the code that did it, but I do remember seeing you test it with a self-signed cert early on.
          Hide
          Donal McMullan added a comment -

          Hi Adam - the webserver cert is absolutely not involved at all... Moodle generates its own certs and keeps them in the config_plugins table of your db.

          So of course, the system assumes that certs are self-signed. BUT the system DOES check to make sure that the cert's CN (canonical name) matches the wwwroot of the webserver that provided it.

          I'm still not convinced that this is your issue. It actually looks more like your certificate is getting garbled somewhere along the way, as if for example a character was being dropped.

          Show
          Donal McMullan added a comment - Hi Adam - the webserver cert is absolutely not involved at all... Moodle generates its own certs and keeps them in the config_plugins table of your db. So of course, the system assumes that certs are self-signed. BUT the system DOES check to make sure that the cert's CN (canonical name) matches the wwwroot of the webserver that provided it. I'm still not convinced that this is your issue. It actually looks more like your certificate is getting garbled somewhere along the way, as if for example a character was being dropped.
          Hide
          Donal McMullan added a comment -

          Hang on - is Adam running this over https on 443? Ah! So maybe I was being too strict in the curl call. Thanks Martin - I'll go check that out.

          Show
          Donal McMullan added a comment - Hang on - is Adam running this over https on 443? Ah! So maybe I was being too strict in the curl call. Thanks Martin - I'll go check that out.
          Hide
          Martín Langhoff added a comment -

          Exactly - and I'm not crazy after all - we did have it on our dev code.

          Originally introduced on the mdl-mnet-rpc branch, here

          commit 9a183ae58674229a20bb941d30a89da91e315b4e
          Author: Donal McMullan <donal@catalyst.net.nz>
          Date: Thu Sep 21 15:10:17 2006 +1200

          mnet: A rewrite of mnet to more closely reflect Moodle coding standards

          And then see commits (on mdl17-mnet branch)

          commit 17140e64cb07d8f94cf4278c7e26bbddb2267322
          Author: Donal McMullan <donal@catalyst.net.nz>
          Date: Thu Dec 21 14:03:13 2006 +1300

          mnet/lib: get_public_key now uses xmlrpc - eating our own dogfood!

          commit 17604c6823ee8d4f041c58fdaf6d2062bdc2cb60
          Author: Donal McMullan <donal@catalyst.net.nz>
          Date: Fri Nov 10 10:48:24 2006 +1300

          mnet: Added xmlrpc directory and moved implementation-specific files there

          commit 680de120b8df85813bf331848fd8d574da2d4de5
          Author: Donal McMullan <donal@catalyst.net.nz>
          Date: Thu Nov 9 13:21:20 2006 +1300

          mnet: New peer class for all RPC implementations

          commit 13122c2e76a912362d5ad4bb6ee9d9e435f39093
          Author: Donal McMullan <donal@catalyst.net.nz>
          Date: Fri Oct 27 14:39:39 2006 +1300

          MNet: Rebase of moodle network architecture on the 1.7 branch

          ======

          I got this info doing

          git whatchanged -p -S'CURLOPT_SSL' origin/mdl-mnet-rpc – mnet lib/mnet
          git whatchanged -p -S'CURLOPT_SSL' origin/mdl17-mnet – mnet lib/mnet

          The code never appears in mdl18-mnet or in cvshead.

          Show
          Martín Langhoff added a comment - Exactly - and I'm not crazy after all - we did have it on our dev code. Originally introduced on the mdl-mnet-rpc branch, here commit 9a183ae58674229a20bb941d30a89da91e315b4e Author: Donal McMullan <donal@catalyst.net.nz> Date: Thu Sep 21 15:10:17 2006 +1200 mnet: A rewrite of mnet to more closely reflect Moodle coding standards And then see commits (on mdl17-mnet branch) commit 17140e64cb07d8f94cf4278c7e26bbddb2267322 Author: Donal McMullan <donal@catalyst.net.nz> Date: Thu Dec 21 14:03:13 2006 +1300 mnet/lib: get_public_key now uses xmlrpc - eating our own dogfood! commit 17604c6823ee8d4f041c58fdaf6d2062bdc2cb60 Author: Donal McMullan <donal@catalyst.net.nz> Date: Fri Nov 10 10:48:24 2006 +1300 mnet: Added xmlrpc directory and moved implementation-specific files there commit 680de120b8df85813bf331848fd8d574da2d4de5 Author: Donal McMullan <donal@catalyst.net.nz> Date: Thu Nov 9 13:21:20 2006 +1300 mnet: New peer class for all RPC implementations commit 13122c2e76a912362d5ad4bb6ee9d9e435f39093 Author: Donal McMullan <donal@catalyst.net.nz> Date: Fri Oct 27 14:39:39 2006 +1300 MNet: Rebase of moodle network architecture on the 1.7 branch ====== I got this info doing git whatchanged -p -S'CURLOPT_SSL' origin/mdl-mnet-rpc – mnet lib/mnet git whatchanged -p -S'CURLOPT_SSL' origin/mdl17-mnet – mnet lib/mnet The code never appears in mdl18-mnet or in cvshead.
          Hide
          Donal McMullan added a comment -

          It looks like the "remote" host is requesting a XMLRPC doc from the "local" host, and what it's receiving is badly formed somehow. I don't think it's not encrypted, because there's no way for it not to be.

          It's possible that the "local" host is encountering an unexpected error and returning something that isn't even remotely XML.

          It's also possible that the "local" host is returning a well-formed XML-ENC doc, but the remote host is failing to parse it properly (which would be a problem in mnet/xmlrpc/xmlparser.php).

          Show
          Donal McMullan added a comment - It looks like the "remote" host is requesting a XMLRPC doc from the "local" host, and what it's receiving is badly formed somehow. I don't think it's not encrypted, because there's no way for it not to be. It's possible that the "local" host is encountering an unexpected error and returning something that isn't even remotely XML. It's also possible that the "local" host is returning a well-formed XML-ENC doc, but the remote host is failing to parse it properly (which would be a problem in mnet/xmlrpc/xmlparser.php).
          Hide
          Martín Langhoff added a comment -

          Looking at

          60:SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:func(144):reason(134)

          I'd say at least one end is not accepting self-signed certs. From the errors posted by Adam, we're failing at the curl stage (as you point out, it may be the remote end calling back), and I doubt we ever get to see the XML to encode/decode.

          Show
          Martín Langhoff added a comment - Looking at 60:SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:func(144):reason(134) I'd say at least one end is not accepting self-signed certs. From the errors posted by Adam, we're failing at the curl stage (as you point out, it may be the remote end calling back), and I doubt we ever get to see the XML to encode/decode.
          Hide
          Donal McMullan added a comment -

          I think it's ok to accept self-signed certs by default - I'll update head.

          Maybe I should create a switch in config_plugins that allows people to tighten this up if they want (using their favourite db client)?

          Show
          Donal McMullan added a comment - I think it's ok to accept self-signed certs by default - I'll update head. Maybe I should create a switch in config_plugins that allows people to tighten this up if they want (using their favourite db client)?
          Hide
          Martin Dougiamas added a comment -

          Feel free to make these kind of fixes in 1.8 as well, as long as they're improvements and don't require extra tables etc

          Show
          Martin Dougiamas added a comment - Feel free to make these kind of fixes in 1.8 as well, as long as they're improvements and don't require extra tables etc
          Hide
          Donal McMullan added a comment -

          In the interim, I've updated MOODLE_18_STABLE and MOODLE_HEAD to not require that https servers use signed certificates. The commit is attached as a patch to MOODLE_18_STABLE.

          Show
          Donal McMullan added a comment - In the interim, I've updated MOODLE_18_STABLE and MOODLE_HEAD to not require that https servers use signed certificates. The commit is attached as a patch to MOODLE_18_STABLE.
          Hide
          Adam Lambert added a comment -

          Well, those patches did not fix the problem. However, one of the two error messages is slightly different. These are the two I am getting now (oddly, one from the /moodleone/ install of moodle, and the other from /peer/ insall).

          From /moodleone/, when trying to hop over to /peer/ I get:

          RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:
          1:Payload not encrypted

          And from /peer/, when trying to hop over to /moodleone/ I get:

          RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [[encryption-invalid]] ERROR 2:
          2:Payload not signed: faultCode 7023 faultString [[encryption-invalid]]

          Any suggestions? Anyone working on this bug do IRC? Perhaps we could speed up the debug process with some live 'try this' exercises.

          Thanks.

          Show
          Adam Lambert added a comment - Well, those patches did not fix the problem. However, one of the two error messages is slightly different. These are the two I am getting now (oddly, one from the /moodleone/ install of moodle, and the other from /peer/ insall). From /moodleone/, when trying to hop over to /peer/ I get: RPC auth/mnet/user_authorise:Payload not encryptedERROR 1: 1:Payload not encrypted And from /peer/, when trying to hop over to /moodleone/ I get: RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [ [encryption-invalid] ] ERROR 2: 2:Payload not signed: faultCode 7023 faultString [ [encryption-invalid] ] Any suggestions? Anyone working on this bug do IRC? Perhaps we could speed up the debug process with some live 'try this' exercises. Thanks.
          Hide
          Donal McMullan added a comment -

          If you go to the page:
          admin/mnet/peers.php
          on each of your Moodles, and you click on the link to look at the details of the other Moodle, do the "Public Key" and the "Valid Until" appear to be ok?

          I don't think Moodle has it's own IRC channel but I (Spaceman`) am often (NZ office hours) in #mahara and #opensolaris on freenode. I'd be happy to run through some stuff there.

          Show
          Donal McMullan added a comment - If you go to the page: admin/mnet/peers.php on each of your Moodles, and you click on the link to look at the details of the other Moodle, do the "Public Key" and the "Valid Until" appear to be ok? I don't think Moodle has it's own IRC channel but I (Spaceman`) am often (NZ office hours) in #mahara and #opensolaris on freenode. I'd be happy to run through some stuff there.
          Hide
          Adam Lambert added a comment -

          First - apologies for slow response; got dragged into another project. I'm no back with some time to devote to this issue again.

          Yes, the keys, and their dates appear to be just fine.

          What NZ hours are you on? Let me know what hours (local to you) you're around, and I'll make arrangements to catch up with you if I can. 4pm my time is 10am your time - so if you wake up this morning and get online before 11, I can be available.

          Thanks,

          Show
          Adam Lambert added a comment - First - apologies for slow response; got dragged into another project. I'm no back with some time to devote to this issue again. Yes, the keys, and their dates appear to be just fine. What NZ hours are you on? Let me know what hours (local to you) you're around, and I'll make arrangements to catch up with you if I can. 4pm my time is 10am your time - so if you wake up this morning and get online before 11, I can be available. Thanks,
          Hide
          Adam Lambert added a comment -

          I don't believe it! For whatever reason, sitting down with it now, it's working. I didn't change anything!!!

          No ideas what to report, other than I can no longer recreate the problem for testing and fixing purposes...

          Thanks,

          Show
          Adam Lambert added a comment - I don't believe it! For whatever reason, sitting down with it now, it's working. I didn't change anything!!! No ideas what to report, other than I can no longer recreate the problem for testing and fixing purposes... Thanks,
          Hide
          Donal McMullan added a comment -

          Woah! The only think I can think of that might explain that, is if your servers re-keyed, but the dates on your bug report don't really support this. They should re-key every month or so... 28 days if I remember correctly.

          Anyway - thanks for the detailed report Adam.

          Cheers - Donal

          Show
          Donal McMullan added a comment - Woah! The only think I can think of that might explain that, is if your servers re-keyed, but the dates on your bug report don't really support this. They should re-key every month or so... 28 days if I remember correctly. Anyway - thanks for the detailed report Adam. Cheers - Donal
          Hide
          Lori Bakken added a comment -

          I've just tried to setup networking as well and I am receiving a similar error when going to a peer:

          RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:2:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record.

          Maybe it isn't fixed?

          Show
          Lori Bakken added a comment - I've just tried to setup networking as well and I am receiving a similar error when going to a peer: RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:2:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. Maybe it isn't fixed?
          Hide
          Donal McMullan added a comment -

          Hi Lori - it seems like this is a different error. Has the IP address of either of your servers changed since you set them up?

          Show
          Donal McMullan added a comment - Hi Lori - it seems like this is a different error. Has the IP address of either of your servers changed since you set them up?
          Hide
          Brian King added a comment -

          I'm seeing this issue. I today downloaded the latest tarballs of moodle 1.8 and moodle 1.9. They are installed on seperate subdomains on the same physical server. If I try to connect via mnet from one of these servers to the other, i see:
          RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted

          The public keys look fine. I did regenerate them, just in case.

          Show
          Brian King added a comment - I'm seeing this issue. I today downloaded the latest tarballs of moodle 1.8 and moodle 1.9. They are installed on seperate subdomains on the same physical server. If I try to connect via mnet from one of these servers to the other, i see: RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted The public keys look fine. I did regenerate them, just in case.
          Hide
          Lori Bakken added a comment -

          Does this create an actual file in the moodle directory??

          When I was creating my play instances I accidentally forgot to change a value in my config file. When I set up networking, I got the same error as Brian. So I dropped my tables and my moodle dir and started over, and then it worked fine.

          So maybe there a discrepancy in a file that moodle creates on install?

          Just a thought.

          Show
          Lori Bakken added a comment - Does this create an actual file in the moodle directory?? When I was creating my play instances I accidentally forgot to change a value in my config file. When I set up networking, I got the same error as Brian. So I dropped my tables and my moodle dir and started over, and then it worked fine. So maybe there a discrepancy in a file that moodle creates on install? Just a thought.
          Hide
          Donal McMullan added a comment -

          Hi Lori - no, the MNet stuff all goes into the database.
          Do you remember which config variable you changed? I might be able to run a test.

          Show
          Donal McMullan added a comment - Hi Lori - no, the MNet stuff all goes into the database. Do you remember which config variable you changed? I might be able to run a test.
          Hide
          Adam Lambert added a comment -

          It's back..... I now am getting this from one side trying to access the other

          RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [[encryption-invalid]] ERROR 2:
          2:Payload not signed: faultCode 7023 faultString [[encryption-invalid]]

          And from the other side trying to access the main site, I get:

          RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:
          1:Payload not encrypted

          .......

          Show
          Adam Lambert added a comment - It's back..... I now am getting this from one side trying to access the other RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [ [encryption-invalid] ] ERROR 2: 2:Payload not signed: faultCode 7023 faultString [ [encryption-invalid] ] And from the other side trying to access the main site, I get: RPC auth/mnet/user_authorise:Payload not encryptedERROR 1: 1:Payload not encrypted .......
          Hide
          Adam Lambert added a comment -

          OK, I'm a dummy. Original installs had defaulted to share the same moodledata directory. This is bad. Some re-installs later, and I now have 3 networked sites happily talking to each other. My problem entirely. Feel free to close this bug - at least as far as for me goes. I saw someone report a slightly different problem back up the comment thread that might need their own bug ticket and/or further help on this ticket.

          Thanks everyone!

          Show
          Adam Lambert added a comment - OK, I'm a dummy. Original installs had defaulted to share the same moodledata directory. This is bad. Some re-installs later, and I now have 3 networked sites happily talking to each other. My problem entirely. Feel free to close this bug - at least as far as for me goes. I saw someone report a slightly different problem back up the comment thread that might need their own bug ticket and/or further help on this ticket. Thanks everyone!
          Hide
          Lori Bakken added a comment -

          I'm getting the IP doesn't match now.

          I had to change the ip of one of my instances... when I did this, I deleted the hosts, Re-entered them (because the IP changed,and re-did the keys.

          Now I can't get it to communicate at all, and I even deleted some things out of the db (in the hosts and peers mnet tables).

          So something is still keyed or holding on to the old ip I think.

          Show
          Lori Bakken added a comment - I'm getting the IP doesn't match now. I had to change the ip of one of my instances... when I did this, I deleted the hosts, Re-entered them (because the IP changed,and re-did the keys. Now I can't get it to communicate at all, and I even deleted some things out of the db (in the hosts and peers mnet tables). So something is still keyed or holding on to the old ip I think.
          Hide
          Lori Bakken added a comment -

          Just to add – I did 2 clean install instances and tried to network them and I'm still getting:

          RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:,2: Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record.

          HELP! I have to get this working!

          Show
          Lori Bakken added a comment - Just to add – I did 2 clean install instances and tried to network them and I'm still getting: RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:,2: Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. HELP! I have to get this working!
          Hide
          Lori Bakken added a comment -

          Ok It definitely has something to do with openssl_open line in ment/xmlrpc/client.php Line 218 – using 1.8.1

          That's when I get the error message. I echoed $payload before when its ' ' and after $payload = faultCode 7017 faultString Your IP address does not match the address we have on record.
          But openssl_open does return 1.

          So where is this failing?

          Show
          Lori Bakken added a comment - Ok It definitely has something to do with openssl_open line in ment/xmlrpc/client.php Line 218 – using 1.8.1 That's when I get the error message. I echoed $payload before when its ' ' and after $payload = faultCode 7017 faultString Your IP address does not match the address we have on record. But openssl_open does return 1. So where is this failing?
          Hide
          Donal McMullan added a comment - - edited

          Lori - are any of the following true:

          • You're running at least one of your hosts on a webserver that isn't Apache
          • You're using fake web addresses via virtual-host files or somesuch
          • One of your webservers doesn't know its own hostname
          • Your webserver(s) have multiple IP addresses

          Can you tell me what platform(s) you're running these on? Sorry you're having problems with this code... I'll try to help if I can.

          Show
          Donal McMullan added a comment - - edited Lori - are any of the following true: You're running at least one of your hosts on a webserver that isn't Apache You're using fake web addresses via virtual-host files or somesuch One of your webservers doesn't know its own hostname Your webserver(s) have multiple IP addresses Can you tell me what platform(s) you're running these on? Sorry you're having problems with this code... I'll try to help if I can.
          Hide
          Lori Bakken added a comment -

          Hi Donal,

          Everything is on 1 apache server with multiple IP's assigned to 1 card

          I have a bunch of websites on 1 ip

          I have what is our main moodle instance on 1 ip, and the rest on another.

          So Moodle A has xxx.xxx.xxx.17 Trying to network with Moodle B at xxx.xxx.xxx.23 on the same machine

          I had it working when moodle A and moodle B were on the same IP but we want secure logins on Moodle A (no login on moodle B) so I re-did my apache config and gave it its own ip. So just as a test I Put another instance up on xxx.xxx.xxx.23 and tried to network moodle B and moodle C, and still get the same message.

          This is on SLES 10, Apache 2.2 (I believe). Thanks for helping.

          Show
          Lori Bakken added a comment - Hi Donal, Everything is on 1 apache server with multiple IP's assigned to 1 card I have a bunch of websites on 1 ip I have what is our main moodle instance on 1 ip, and the rest on another. So Moodle A has xxx.xxx.xxx.17 Trying to network with Moodle B at xxx.xxx.xxx.23 on the same machine I had it working when moodle A and moodle B were on the same IP but we want secure logins on Moodle A (no login on moodle B) so I re-did my apache config and gave it its own ip. So just as a test I Put another instance up on xxx.xxx.xxx.23 and tried to network moodle B and moodle C, and still get the same message. This is on SLES 10, Apache 2.2 (I believe). Thanks for helping.
          Hide
          Jens Gammelgaard added a comment -

          Hi Lori,

          Have you tried to renew the keys and copy and paste them to the moodles that you peer?

          Under some settings this should be done (renewed) automatically, - but it is not.

          BR
          Jens

          Show
          Jens Gammelgaard added a comment - Hi Lori, Have you tried to renew the keys and copy and paste them to the moodles that you peer? Under some settings this should be done (renewed) automatically, - but it is not. BR Jens
          Hide
          Lori Bakken added a comment -

          I have many times Jens.

          For some more info - I have 3 additional instances on the same ip on the same server all on .23, moohub1, moohub2, moohub3 -
          I was testing out the networking with these instances, and those ones still work exactly how they should. But for some reason, It won't go on our ecampus (main point of entry) to eclass.

          So its something specifically with those instances. not the server, because if it was the server it would have changed the moohub ones.

          Also like I've said before I've done a complete wipe of those instances (db and files) and started from scratch and still no dice.

          Lori

          Show
          Lori Bakken added a comment - I have many times Jens. For some more info - I have 3 additional instances on the same ip on the same server all on .23, moohub1, moohub2, moohub3 - I was testing out the networking with these instances, and those ones still work exactly how they should. But for some reason, It won't go on our ecampus (main point of entry) to eclass. So its something specifically with those instances. not the server, because if it was the server it would have changed the moohub ones. Also like I've said before I've done a complete wipe of those instances (db and files) and started from scratch and still no dice. Lori
          Hide
          Lori Bakken added a comment -

          Hi All,

          After being on holidays, I installed 2 new instances with 1.8.2 and I'm still getting the same error. It is really critical that I get this working.

          As an update, I moved the ip back to .23 --> the ip where I share all the other instance – where it originally worked , and it is working again,

          The funny thing is, on eClass (2nd instance) I have eCampus (login point) listed as a peer and .17 is still showing as its ip, but connectivity is still good. So it is working now, but I can't use this ip for ssl logins.

          So narrowed down, it looks like its probably an apache type issue with having multiple ip's, and virtual hosts. Is there a way around this?

          Show
          Lori Bakken added a comment - Hi All, After being on holidays, I installed 2 new instances with 1.8.2 and I'm still getting the same error. It is really critical that I get this working. As an update, I moved the ip back to .23 --> the ip where I share all the other instance – where it originally worked , and it is working again, The funny thing is, on eClass (2nd instance) I have eCampus (login point) listed as a peer and .17 is still showing as its ip, but connectivity is still good. So it is working now, but I can't use this ip for ssl logins. So narrowed down, it looks like its probably an apache type issue with having multiple ip's, and virtual hosts. Is there a way around this?
          Hide
          Donal McMullan added a comment -

          Adam's original problem turned out to be a configuration error. His Moodle instances were sharing a moodledata directory.

          The other issues reported in this bug are dupes of 10672

          Show
          Donal McMullan added a comment - Adam's original problem turned out to be a configuration error. His Moodle instances were sharing a moodledata directory. The other issues reported in this bug are dupes of 10672
          Hide
          Peter Sereinigg added a comment -

          Hi Donal
          Me has the same error, but NOT shared directories ...
          you may check this on my site direct if you like, please contact me if possible!

          Peter

          Show
          Peter Sereinigg added a comment - Hi Donal Me has the same error, but NOT shared directories ... you may check this on my site direct if you like, please contact me if possible! Peter

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: