The "Freeola Customer Forum" forum, which includes Retro Game Reviews, has been archived and is now read-only. You cannot post here or create a new thread or review on this forum.
The Service Status page showed that webserver 4 was having some maintenance carried out yesterday.
I happened to notice some old CGI scripts I use failing this morning on a server 4 website.
Poking about I found that some file permissions have changed from 766 to 744.
This has happened on numerous server 4 sites.
After changing the file permission on the failing script everything is running again.
Freeola, thanks for posting this maintenance work. Without seeing that I would have been scratching my head for a lot longer!
Can you say what the maintenance was and if you will be doing it to all the other web servers in the future?
EDIT:
I thought this was worth a forum post rather than a support ticket as I'm all sorted and others may find it useful if they are affected :¬)
I happened to notice some old CGI scripts I use failing this morning on a server 4 website.
Poking about I found that some file permissions have changed from 766 to 744.
This has happened on numerous server 4 sites.
After changing the file permission on the failing script everything is running again.
Freeola, thanks for posting this maintenance work. Without seeing that I would have been scratching my head for a lot longer!
Can you say what the maintenance was and if you will be doing it to all the other web servers in the future?
[s]Hmmm...[/s]EDIT:
I thought this was worth a forum post rather than a support ticket as I'm all sorted and others may find it useful if they are affected :¬)
Page:
The Service Status page showed that webserver 4 was having some maintenance carried out yesterday.
I happened to notice some old CGI scripts I use failing this morning on a server 4 website.
Poking about I found that some file permissions have changed from 766 to 744.
This has happened on numerous server 4 sites.
After changing the file permission on the failing script everything is running again.
Freeola, thanks for posting this maintenance work. Without seeing that I would have been scratching my head for a lot longer!
Can you say what the maintenance was and if you will be doing it to all the other web servers in the future?
EDIT:
I thought this was worth a forum post rather than a support ticket as I'm all sorted and others may find it useful if they are affected :¬)
I happened to notice some old CGI scripts I use failing this morning on a server 4 website.
Poking about I found that some file permissions have changed from 766 to 744.
This has happened on numerous server 4 sites.
After changing the file permission on the failing script everything is running again.
Freeola, thanks for posting this maintenance work. Without seeing that I would have been scratching my head for a lot longer!
Can you say what the maintenance was and if you will be doing it to all the other web servers in the future?
[s]Hmmm...[/s]EDIT:
I thought this was worth a forum post rather than a support ticket as I'm all sorted and others may find it useful if they are affected :¬)
Hi Hmmm...
Thanks for the feedback. We'll try and get it sorted for next time as we will be performing this maintenance across all the free hosting servers soon. It may that the newer perl configs are slightly different, we did check pretty thoroughly but it would be impossible to check everything is running correctly on every single site.
Thanks for the feedback. We'll try and get it sorted for next time as we will be performing this maintenance across all the free hosting servers soon. It may that the newer perl configs are slightly different, we did check pretty thoroughly but it would be impossible to check everything is running correctly on every single site.
Bump specially for Hmmm... next bit of maintenance
Thank you!
[s]Hmmm...[/s]
Eccles wrote:
Thanks for the feedback. We'll try and get it sorted for next time...
The Status Page hasn't been updated, but I can see file permissions have changed on web server 5 sites like they did for 4 so I'm guessing the 'maintenance' has been carried out...?!
I'm seeing £ characters for sites on server 5 are now displaying corrupted.
I'll raise a ticket.
EDIT: Support Ticket=201536
Thanks for the feedback. We'll try and get it sorted for next time...
The Status Page hasn't been updated, but I can see file permissions have changed on web server 5 sites like they did for 4 so I'm guessing the 'maintenance' has been carried out...?!
I'm seeing £ characters for sites on server 5 are now displaying corrupted.
I'll raise a ticket.
EDIT: Support Ticket=201536
[s]Hmmm...[/s] 
This issue is now resolved - I'm sure you'll get a reply to your support ticket shortly...
It was related to the character set in use on the site you mentioned in your ticket. You'd declared the character set as 'windows-1252', which we hadn't added support for following the maintenance.
Support for this character set has now been added, so this shouldn't cause a problem when other servers are upgraded.
It was related to the character set in use on the site you mentioned in your ticket. You'd declared the character set as 'windows-1252', which we hadn't added support for following the maintenance.
Support for this character set has now been added, so this shouldn't cause a problem when other servers are upgraded.
Thanks for that info.
That is an old (but popular) site! All working now.
Surprised to see the file permissions change again...?
That is an old (but popular) site! All working now.
Surprised to see the file permissions change again...?
[s]Hmmm...[/s]
Hi Freeola,
I'm not sure if this is me or not but I 'think' it could be down to your changes. It's a newly re-written website so i'm not 100% sure...
Using the Freeola standard form-to-mail script I notice on webserver 4 the REPLY address shows as:
Previously it just used to show as from the normal account used in the form.
EDIT:
I've just found that I see the "uid1000/on behalf of" text from sites running on server 4 and 7 (so far) - the message says 'freeolaweb4' for both servers.
NB. Not all email clients will show 'on behalf of'. Desktop MS Outlook does.
Let me know if you need more details.
I'm not sure if this is me or not but I 'think' it could be down to your changes. It's a newly re-written website so i'm not 100% sure...
Using the Freeola standard form-to-mail script I notice on webserver 4 the REPLY address shows as:
From: uid1000 [mailto:[email protected]] On Behalf Of [email protected]Previously it just used to show as from the normal account used in the form.
EDIT:
I've just found that I see the "uid1000/on behalf of" text from sites running on server 4 and 7 (so far) - the message says 'freeolaweb4' for both servers.
NB. Not all email clients will show 'on behalf of'. Desktop MS Outlook does.
Let me know if you need more details.
[s]Hmmm...[/s] 
Hmmm... wrote:
Hi Freeola,
I'm not sure if this is me or not but I 'think' it could be down to your changes. It's a newly re-written website so i'm not 100% sure...
Using the Freeola standard form-to-mail script I notice on webserver 4 the REPLY address shows as:
Previously it just used to show as from the normal account used in the form.
EDIT:
I've just found that I see the "uid1000/on behalf of" text from sites running on server 4 and 7 (so far) - the message says 'freeolaweb4' for both servers.
NB. Not all email clients will show 'on behalf of'. Desktop MS Outlook does.
Let me know if you need more details.
I can't reproduce the reply address being the freeolaweb address As long as you supply a From: header (and the standard form to mail requires this), the return address should be the from address. I've checked it in Outlook 2010 and while I do see the On Behalf of , it still selects the correct address to reply to.
I've set our MTA to not add a sender address (which is what Outlook appears to use to decide to put the on behalf of prefix), and I think that will resolve your issue (unless I misunderstand)
The other part (freeolaweb4) is correct as is (we've consolidated the servers on to much more powerful hardware) and added some redundancy so that we can switch load around if required).
Hi Freeola,
I'm not sure if this is me or not but I 'think' it could be down to your changes. It's a newly re-written website so i'm not 100% sure...
Using the Freeola standard form-to-mail script I notice on webserver 4 the REPLY address shows as:
From: uid1000 [mailto:[email protected]] On Behalf Of [email protected]Previously it just used to show as from the normal account used in the form.
EDIT:
I've just found that I see the "uid1000/on behalf of" text from sites running on server 4 and 7 (so far) - the message says 'freeolaweb4' for both servers.
NB. Not all email clients will show 'on behalf of'. Desktop MS Outlook does.
Let me know if you need more details.
[s]Hmmm...[/s]I can't reproduce the reply address being the freeolaweb address As long as you supply a From: header (and the standard form to mail requires this), the return address should be the from address. I've checked it in Outlook 2010 and while I do see the On Behalf of , it still selects the correct address to reply to.
I've set our MTA to not add a sender address (which is what Outlook appears to use to decide to put the on behalf of prefix), and I think that will resolve your issue (unless I misunderstand)
The other part (freeolaweb4) is correct as is (we've consolidated the servers on to much more powerful hardware) and added some redundancy so that we can switch load around if required).
Thanks for that.
I've just retested and things look as if they have returned to how they were before your 'maintenance'.
i.e. No reference to "uid1000" or "on behalf of" in the message.
:¬)
EDIT:
Previously there was quite a delay after a visitor clicked SEND while the form was processing, which was a bit of a pain as impatient visitors caused double submissions if they clicked more than once. The form now processes immediately which is great!
I've just retested and things look as if they have returned to how they were before your 'maintenance'.
i.e. No reference to "uid1000" or "on behalf of" in the message.
:¬)
[s]Hmmm...[/s]EDIT:
Previously there was quite a delay after a visitor clicked SEND while the form was processing, which was a bit of a pain as impatient visitors caused double submissions if they clicked more than once. The form now processes immediately which is great!
Page: