Is there a list with all the settings for Apache, PHP and MySQL, needed for a good working Moodle?
(Yes we still have these problems, it is now week 9 )
What fascinates me is that Moodle seems to be the only product that switched from our old standalone server to our new SAN-platform, that does not like our new combination. (The normally more critical product Typo3 has not a single problem with it.)
IF I combine this observation with a remark elsewhere in the forums: "that I had to change the relative adress localhost into a fixed adress"...
(Again: the bad behavior of Moodle happens with all the versions of Moodle I tried: 1.4.3+, 1.5.2, 1.6beta)
Can someone of the Moodle experts explain the way Moodle handles webadresses internally ?
in the same thread as Michael refer, there are also some other pending questions waiting for yours answers, if you consider these appropriate to your case.
Another possible solution is to hire the Ironman from Moodle.com "skilled and certified... in the appropriates ICT ( LAMP ) sports".
Thanks again for all your effort. And let me do what you advice:
"Dear Friends of Moodle.com and partners, please do me an offer to solve our problems with Moodle on our new SAN-server:
We are using moodle on a SAN-server with two front-end-systems under https://
I can give you access to our webserver for inspection as admin and with winscp.
The identified problems we have on this moment are:
- the IE browser, loosing contact with the server when it tries to store a form in the database.
(worked before, and problem is not there with firefox..)
- jpeg-pictures are crippled when you store them with winscp (never a problem before)
- excel-export in several modules deliver crippled Excel-dumps. (worked before)
- freezing functionality when you try to create several new courses in a row
- Bernard thinks also that our database is corrupted, so how to repair that (do an offer for this as a separate case)
Please, do me an offer on a no-cure-no-pay-base
now it is very clear for me. As a learning novice in LAMP I will let experts doing their job.
When things will be settled for you ( in a near future I hope ) , I will be interested to know the issues if possible.
Please, do me an offer on a no-cure-no-pay-base
That doesn't seem like a winning strategy, really. To begin with, you definitely have something misconfigured at your end -- this isn't a normal Moodle problem, it's something in your server setup that is broken. That means that you will have to give
ssh access, and probably
root (admin) access, to whoever you contract, so that they can diagnose it. It's not a trivial problem.
When you do that, you want some kind of agreement that defines the responsibilities of the contractor towards you in terms of server security, privacy, etc. To enter into that agreement, smart people want to be paid (you don't want to contract, ahem, non-smart people). And you really want to have a good relationship with a person you entrust with so much access! No-cure-no-pay is used to people you don't trust.
And naturally, the experts you are after do read these forums, and help you already, for free. So you don't need to be so tight, really. I hope you are familiar with the concept of being generous with people who have been generous to you
I think that even smart people would accept an agreement where indemnified against loss and there is a good chance that Ger trust that much.
No-cure-no-pay may also be used when you don't have that much money, or that money is tied to results. I would not be able to pay, with university money, for an attempt at a cure either.
IMHO Ger is generous and expert, so he is bound to be familiar with the concept outlined above.
I agree with Martin, I don't think many folks would want to be teachers if they only got paid for the A students, especially if they had to wait until after the As were earned.
Salaries and bills have to be paid while the work is being done. A standard contract for something like this would be 1/3 to 1/2 of the estimate down, and that would be entirely fair.
- IE and Firefox, on the same machine, can be using different proxies, so it could be a proxy thing even if it's working in FF and not in IE. Double-check which proxies are in use, are they the same?
- Is Typo3 running on the same machine, with the same PHP, Apache and MySQL environment/configs?
- Is there no problems if you store a JPEG image with WinSCP to the Typo3 www root and check it with a browser? How about the Moodle www root? How about inside a static HTML page, is there a difference to the "naked" JPEG file?
- If the JPEG works from Typo3 www root but not from the Moodle www root, you can eliminate the Typo3 and Moodle from the problem: a bare JPEG downloaded directly from the www root doesn't interact with the web app, then it's a pure config problem.
- The next step is to see what's different in those settings. If they are indeed the same, then it's just another config somewhere deeper...
- Is there a gzip module of some sort in use that IE would have trouble with?
- What about the HTTP request and response, are they the same for IE and FF? Is IE receiving the same HTTP response than FF, but still having problems with it? It could be the no-proxy settings that Moodle puts in the headers.
- Try also with static HTML pages that you load from the Moodle www root. Do they work? A simple PHP script?
My problem solving technique for the "full moon and sunspots" type of odd behaviour would be to try to build a simplest case where things don't work, and then the even simplier one where things work, and look for the difference.
I hope you eventually get things fixed. If you do, please remember to tell us what it was.