Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Contributions / Tips&Tricks / Features Requests / Zentyal 2.1 User Corner Internal Server Error (Could not read ) {SOLVED}
« on: December 22, 2016, 05:20:20 pm »
Had an issue in Zentyal 2.2.11, under User Corner.
After logging in to user Corner the server would throw an Internal Server Error
Looking at /var/log/zentyal-user-corner/zentyal.log I found
ERROR> Auth.pm:266 EBox::UserCorner::Auth::authen_ses_key - Could not open /var/lib/zentyal-usercorner/sids/john.doe
"john.doe" is a username.
This is a kind of cookie file Zentyal creates when the user logs in to User Corner.
If the user simply closes the browser without logging out, the file stays there forever.
Somehow there was a particular file it couldn't read and therefore it stopped processing the user Corner page.
Just delete all the files in there that are old. "Old" means they're more than a reasonable amount of minutes. If you're not sure, delete the ones that are more than 1 day of age. Surely the user isn't doing anything by now.
Hope this helps other people overcoming this stupid error.
/var/lib/zentyal-usercorner/sids
After logging in to user Corner the server would throw an Internal Server Error
Looking at /var/log/zentyal-user-corner/zentyal.log I found
ERROR> Auth.pm:266 EBox::UserCorner::Auth::authen_ses_key - Could not open /var/lib/zentyal-usercorner/sids/john.doe
"john.doe" is a username.
This is a kind of cookie file Zentyal creates when the user logs in to User Corner.
If the user simply closes the browser without logging out, the file stays there forever.
Somehow there was a particular file it couldn't read and therefore it stopped processing the user Corner page.
Just delete all the files in there that are old. "Old" means they're more than a reasonable amount of minutes. If you're not sure, delete the ones that are more than 1 day of age. Surely the user isn't doing anything by now.
Hope this helps other people overcoming this stupid error.
/var/lib/zentyal-usercorner/sids
2
Email and Groupware / Re: No logs in MailFilter and white / black list Postgrey do not work
« on: July 08, 2016, 02:05:37 pm »
If you only need to whitelist servers, try point #5. below.
If you need to stop Postgrey for other reasons, read all throughout.
I have further researched into Postgrey in Zentyal. Here's what i've got for Zentyal 2.2.11, on Ubuntu 10.04. Yeah it's that old. But upgrading is such a pain. That's why maybe Zentyal will probably have no future with me in this organization. Also, stuff like this problem we're debating here. On Ubuntu 12 and 14 there are reports of a bug on the postgrey init.d script. But that's another story.
Postgrey is installed on Zentyal with defaults. You open '/etc/default/postgrey' and you see the port 10023 as option. But when you do 'ps -ef | grep postgrey' you see port 60000. So it had to be coming from somewhere. Zentyal, of course.
Stopping Postgrey
Zentyal has set PostGrey on a different way, by running it directly with respawn. Zentyal has a script to stop the default postgrey daemon at boot. And then starts it as a process with it's options and sets respawn on it. Whenever it is killed it is restarted (respawned) automatically.
This script stub is at /usr/share/zentyal/stubs/mail/ebox.postgrey.mas
For this reason, it is practical to make it a daemon.So here's how to do it.
Side effect: If you stop or restart Postgrey by command line, it will not assume the Zentyal Control Panel values. It will assume the defaults at /etc/default/postgrey. That's why we'll change the default daemon config too. Other than for particular reasons, you should normally change postgrey values at the Control Panel.
To get back to Zentyal's way of doing, we should restart the server. Or find out where's this script and how Zentyal calls it. I haven't found it yet.
1. Check what options are being used for PostGrey
$ ps-ef | grep postgrey
postgrey 8627 1 0 Jul05 ? 00:00:19 /usr/sbin/postgrey --inet 127.0.0.1:60000 --delay=300 --max-age=35 --retry-window=48h
Note: --inet 127.0.0.1:60000 is the same as using --inet=60000.
So i have --inet=60000 --delay=300 --max-age=35 --retry-window=48h
2. Make it a daemon
Let's alter Zentyal stub to change it from a process to daemon.
Open /usr/share/zentyal/stubs/mail/ebox.postgrey.mas
At the end, find
exec /usr/sbin/postgrey --inet <% $address %>:<% $port %> <% $params %>
respawn
Change it by adding --daemonize --pidfile=/var/run/postgrey.pid and remove respawn by commenting it.
Note: So that you know. You'll find that the following line in the script stops the postgrey service.
"invoke-rc.d postgrey stop || true"
3. Alter the default daemon
Now we should alter the defaults to the same settings we have at Zentyal, because if you do end up stopping and restarting, you'll want to have the same options. For some reason you might not want to restart the server, but you get the same functionality.
Go to /etc/default/postgrey
Find POSTGREY_OPTS="--inet=10023"
Change to
4. Apply the new config
Restart the server (or find how to use Zentyal's script*). Now you should be able to get service status from postgrey
$sudo service postgrey status
* postgrey is running
5. Add servers to whitelist
You should use, and if necessary, create /etc/postgrey/whitelist_clients.local file.
Or else Zentyal will overwrite whitelist_clients at boot using the stub /usr/share/zentyal/stubs/mailwhitelist_clients.mas. Using whitelist_clients.local file will make you safe from all that nonsense.
If you need to stop Postgrey for other reasons, read all throughout.
I have further researched into Postgrey in Zentyal. Here's what i've got for Zentyal 2.2.11, on Ubuntu 10.04. Yeah it's that old. But upgrading is such a pain. That's why maybe Zentyal will probably have no future with me in this organization. Also, stuff like this problem we're debating here. On Ubuntu 12 and 14 there are reports of a bug on the postgrey init.d script. But that's another story.
Postgrey is installed on Zentyal with defaults. You open '/etc/default/postgrey' and you see the port 10023 as option. But when you do 'ps -ef | grep postgrey' you see port 60000. So it had to be coming from somewhere. Zentyal, of course.
Stopping Postgrey
Zentyal has set PostGrey on a different way, by running it directly with respawn. Zentyal has a script to stop the default postgrey daemon at boot. And then starts it as a process with it's options and sets respawn on it. Whenever it is killed it is restarted (respawned) automatically.
This script stub is at /usr/share/zentyal/stubs/mail/ebox.postgrey.mas
For this reason, it is practical to make it a daemon.So here's how to do it.
Side effect: If you stop or restart Postgrey by command line, it will not assume the Zentyal Control Panel values. It will assume the defaults at /etc/default/postgrey. That's why we'll change the default daemon config too. Other than for particular reasons, you should normally change postgrey values at the Control Panel.
To get back to Zentyal's way of doing, we should restart the server. Or find out where's this script and how Zentyal calls it. I haven't found it yet.
1. Check what options are being used for PostGrey
$ ps-ef | grep postgrey
postgrey 8627 1 0 Jul05 ? 00:00:19 /usr/sbin/postgrey --inet 127.0.0.1:60000 --delay=300 --max-age=35 --retry-window=48h
Note: --inet 127.0.0.1:60000 is the same as using --inet=60000.
So i have --inet=60000 --delay=300 --max-age=35 --retry-window=48h
2. Make it a daemon
Let's alter Zentyal stub to change it from a process to daemon.
Open /usr/share/zentyal/stubs/mail/ebox.postgrey.mas
At the end, find
exec /usr/sbin/postgrey --inet <% $address %>:<% $port %> <% $params %>
respawn
Change it by adding --daemonize --pidfile=/var/run/postgrey.pid and remove respawn by commenting it.
Code: [Select]
exec /usr/sbin/postgrey --inet <% $address %>:<% $port %> <% $params %> --daemonize --pidfile=/var/run/postgrey.pid
#respawnNote: So that you know. You'll find that the following line in the script stops the postgrey service.
"invoke-rc.d postgrey stop || true"
3. Alter the default daemon
Now we should alter the defaults to the same settings we have at Zentyal, because if you do end up stopping and restarting, you'll want to have the same options. For some reason you might not want to restart the server, but you get the same functionality.
Go to /etc/default/postgrey
Find POSTGREY_OPTS="--inet=10023"
Change to
Code: [Select]
#POSTGREY_OPTS="--inet=10023"
POSTGREY_OPTS="--inet=60000 --delay=300 --max-age=35 --retry-window=48h"
4. Apply the new config
Restart the server (or find how to use Zentyal's script*). Now you should be able to get service status from postgrey
$sudo service postgrey status
* postgrey is running
5. Add servers to whitelist
You should use, and if necessary, create /etc/postgrey/whitelist_clients.local file.
Or else Zentyal will overwrite whitelist_clients at boot using the stub /usr/share/zentyal/stubs/mailwhitelist_clients.mas. Using whitelist_clients.local file will make you safe from all that nonsense.
3
Email and Groupware / Re: No logs in MailFilter and white / black list Postgrey do not work
« on: July 06, 2016, 06:52:36 pm »
Did you restart the machine? That proves more effective than killing and starting postgrey.
I also have problems to kill the process. If i kill it it a new one will start right away automatically. I'm a noob on this too.
I also have problems to kill the process. If i kill it it a new one will start right away automatically. I'm a noob on this too.
4
Email and Groupware / Re: No logs in MailFilter and white / black list Postgrey do not work
« on: July 05, 2016, 11:17:01 am »
Just been there, got the tshirt too 
.
Executing "service postgrey restart" does nothing. You must kill the service through its pid or restart the machine.
According to this, postgrey has a bug in Ubuntu 12 and 14 (at least). They did fix it during Ubuntu 14, or so it seems.
As a first approach, setting it in /etc/postgrey/whitelist_clients and killing the process + starting the service through "sudo service postgrey start" will give you immediate results.
Just remember to save the final rules in the stub whitelist_clients.mas or else they will go away after reboot.
Editing the stubs via /usr/share/zentyal/stubs/mail/whitelist_clients.mas will have Zentyal overwrite the file /etc/postgrey/whitelist_clients everytime after reboot. So it's always a good idea to set the rules there with the final version of the rules.
This goes the same way for any other setting for any files under the stubs.
. Executing "service postgrey restart" does nothing. You must kill the service through its pid or restart the machine.
According to this, postgrey has a bug in Ubuntu 12 and 14 (at least). They did fix it during Ubuntu 14, or so it seems.
As a first approach, setting it in /etc/postgrey/whitelist_clients and killing the process + starting the service through "sudo service postgrey start" will give you immediate results.
Just remember to save the final rules in the stub whitelist_clients.mas or else they will go away after reboot.
Editing the stubs via /usr/share/zentyal/stubs/mail/whitelist_clients.mas will have Zentyal overwrite the file /etc/postgrey/whitelist_clients everytime after reboot. So it's always a good idea to set the rules there with the final version of the rules.
This goes the same way for any other setting for any files under the stubs.
Pages: [1]