Hello Matthew! >>> Very strange, though. If you turn the log level in Apache down to >>> debug, you should get a pretty comprehensive trace of what's being >>> done; that info might help pinpoint the cause of the trouble. >> I'll do that and click through the Typo3 backend and hope that the error >> accurs soon. As this is a live server with many paying customers on it I >> cannot do this very long. ;-) I'll be back with the result soon. > You don't have a staging/test environment where you can try out things > like this?
Yes and no. >> But as written above: This is a live server and as our own policy we do >> not compile any packages. We only use "final" packages. Well, not the >> best idea to use a hybrid system with stable and unstable packages, but >> stable is sometimes really unusable for us. > I'd go beyond "not the best idea", all the way to "downright foolhardy". > Unstable is, on occasion, quite unstable, and only running pre-packaged > versions severely cramps your style in deploying bugfixes and customising > software to suit your needs -- the very *epitomy* of what Free Software > gives you. Well, our setup runs nearly perfect for about 4 years now. We have several server and we _always_ test new packages on our failover-/testing-server before installing onto the main servers. But: Some bugs are hard to find, e.g. the bug we are talking about in this bug report thread. I cannot build a identical testing system because of many reasons. One reason is the time, another reason is that we do not have a complete overview of everything that customers run on their webspaces. And even if we have a complete overview, there's the other reason again: time. Talking again about the bug here: It is really hard to find and only appears _sometimes_ and when clicking through the backend of Typo3. So I have two options: 1) never update, never touch a running system (until it gets hacked etc) and 2) test as good as possible and then install it on the live machine (if everything fails including downgrading via dpkg we still can restore a system backup which is not older than one day). > I know something of what I speak of here, too -- one of things I do in my > job is put together new and customised packages to suit business needs. > It's *crucial* to being able to give the best possible result, especially > if you're using a moving target / possibly dangerously buggy suite of > packages. > I'm not trying to be harsh, but seriously, kill that policy. And setup a > Xen instance to test things out on. We do have a kind of testing environment. Sure, our tests could be more serious, but I think we do enough. The last years showed us that it works. Plus we have a perfect backup solution and can always go back if things go really bad. The policy about a stable/unstable hybrid system: We really like it and only got problems very rarly. But all problems could be solved quickly, most of the time with a downgrade to the privious version. But thank you for your words. Sure always the best way is to test everything very accurate and only use long tested software versions (stable). But as a German proverb says: In theory there's no difference between theory and practice. But in practice there is. ;-) But coming back to the bug: I continue test on the live system. Logfiles will get a bit bigger and performance will decrease a bit. But I don't have the time to set up a exact clone of this environment. Also I don't have any bugfree package of libapache2-mod-auth-mysql I can use on the live server. So I keep the version running on it right now. Regards, Martin
