Hi, I have configured Policyd in Zimbra 8.0.2 Ubuntu after the main installation and it is not working.
The configuration I have followed is this: -enabling-cbpolicyd-zimbra-8-0-0-8-0-1-a.html
I can access the PolicyD page, but not the database. The error is this: Error connecting to Policyd v2 DB: could not find driver
My PHPINFO() shows:
PDO
PDO support enabled
PDO drivers sqlite
pdo_sqlite
PDO Driver for SQLite 3.x enabled
SQLite Library 3.7.7.1
The database configured in config.php is SQLLITE.
Can someone help me to address whats missing?
thanks a lot
Andre
CBPolicyD - Problems after Installation and setup
-
andre.paiz
- Posts: 3
- Joined: Sat Sep 13, 2014 3:05 am
CBPolicyD - Problems after Installation and setup
these instructions aren't complete. the default path in the cluebringer-httpd.conf refers to /usr/share/cluebringer/webui. If you unpack the cluebringer webui into this path, make sure you also copy/edit the correct config into /usr/share/cluebringer/webui/includes/config.php. Then it works.
CBPolicyD - Problems after Installation and setup
also, i'm not sure that step 2 (database initialisation) is correct - i think the database is already initialised and this leads to duplicate entries. in addition, i'm not sure that adding the zimbraMtaRestriction is correct - it's already in postfix in a different format.
CBPolicyD - Problems after Installation and setup
I'm not sure why you are following directions from Zextras website. They are clearly wrong.
I would probably read Postfix Policyd - Zimbra :: Wiki
--Quanah
I would probably read Postfix Policyd - Zimbra :: Wiki
--Quanah
--
Quanah Gibson-Mount
Product Architect, Symas http://www.symas.com/
OpenLDAP Core team http://www.openldap.org/project/
Quanah Gibson-Mount
Product Architect, Symas http://www.symas.com/
OpenLDAP Core team http://www.openldap.org/project/
CBPolicyD - Problems after Installation and setup
Hello Gentlemen,
I honestly had not any issue following that guide:
[quote user="dijichi2"]these instructions aren't complete. the default path in the cluebringer-httpd.conf refers to /usr/share/cluebringer/webui. If you unpack the cluebringer webui into this path, make sure you also copy/edit the correct config into /usr/share/cluebringer/webui/includes/config.php. Then it works.[/QUOTE]
In zimbra's cluebringer-httpd.conf file I can see no reference to such folder and zimbra's cluebringer config.php is in /opt/zimbra/cbpolicyd/share/webui/includes/ anyways... Are you using the cbpolicyd distributed wiht zimbra or did you install cbpolicyd from scratch?
[quote user="dijichi2"]also, i'm not sure that step 2 (database initialisation) is correct - i think the database is already initialised and this leads to duplicate entries. in addition, i'm not sure that adding the zimbraMtaRestriction is correct - it's already in postfix in a different format.[/QUOTE]
I still have to try this on Zimbra 8.0.2, but in 8.0.1 the database had to be manually initialized.
The zimbraMtaRestriction wasn't there when cbpolicyd was first included in Zimbra, and the guide states to add it only if needed.
[quote user="quanah"]I'm not sure why you are following directions from Zextras website. They are clearly wrong.
I would probably read Postfix Policyd - Zimbra :: Wiki
--Quanah[/QUOTE]
As I said I still have to try this on 8.0.2, but unfortunately from my personal experience the instructions you link are far from complete...
My 2 c.
I honestly had not any issue following that guide:
[quote user="dijichi2"]these instructions aren't complete. the default path in the cluebringer-httpd.conf refers to /usr/share/cluebringer/webui. If you unpack the cluebringer webui into this path, make sure you also copy/edit the correct config into /usr/share/cluebringer/webui/includes/config.php. Then it works.[/QUOTE]
In zimbra's cluebringer-httpd.conf file I can see no reference to such folder and zimbra's cluebringer config.php is in /opt/zimbra/cbpolicyd/share/webui/includes/ anyways... Are you using the cbpolicyd distributed wiht zimbra or did you install cbpolicyd from scratch?
[quote user="dijichi2"]also, i'm not sure that step 2 (database initialisation) is correct - i think the database is already initialised and this leads to duplicate entries. in addition, i'm not sure that adding the zimbraMtaRestriction is correct - it's already in postfix in a different format.[/QUOTE]
I still have to try this on Zimbra 8.0.2, but in 8.0.1 the database had to be manually initialized.
The zimbraMtaRestriction wasn't there when cbpolicyd was first included in Zimbra, and the guide states to add it only if needed.
[quote user="quanah"]I'm not sure why you are following directions from Zextras website. They are clearly wrong.
I would probably read Postfix Policyd - Zimbra :: Wiki
--Quanah[/QUOTE]
As I said I still have to try this on 8.0.2, but unfortunately from my personal experience the instructions you link are far from complete...
My 2 c.
CBPolicyD - Problems after Installation and setup
the instructions quanah left are unfortunately complete. i say unfortunately, because they are enough to get policyd up and running with zimbra (at least in 8.0.2/8.0.3), it doesn't really do anything that I can see. as detailed on that page you can even set greylisting option in zmlocalconfig, but again it doesn't really do anything, at least as far as I can see.
what I do like about zimbra's approach to this is that it's easy. a single command:
zmprov ms +zimbraServiceEnabled cbpolicyd
zmconfig will then spring into action on it's next invocation and rewrite the necessary postfix config to hook policyd in. if the policyd sqlite database is missing, it will indeed create it for you. you can also invoke this manually using zmcbpolicydctl - if this doesn't find the db it will create it. this is very nice. do not follow the instructions on the zextras page.
what I don't like about zimbra's approach to this is that it appears to be the usual half-baked implementation that you still have to go out and hack around by hand to get it to work effectively (think dspam, spamassassin etc). plus, they've deliberately stripped out the useful bits you need to do this (web interface). plus, any hacks put into place to get it working ala zextras way get wiped out every upgrade. the zextras wiki pages are not the best way to go about it as it tries to repair the zimbra, and let's be honest - bodging an antispam web interface into an internal zimbra apache instance meant to serve spelling on some random port, is not really the ideal situation. i'm amazed that zimbra still has this huge dependency stack just to serve spell check, surely there's a way of doing this without an entire cumbersome apache/php stack?
imho you're much better off just installing/using the proper OS apache, installing cluebringer into a more suitable place like /usr/share/cluebringer, or in your http/vhosts tree somewhere, and configuring it to point to the zimbra cb database (/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb). this then sits outside of zimbra and won't be interfered with by zimbra.
as to getting it to actually do something, i'll post back again if I get anywhere. the last time I tried to get it to greylist, it wouldn't do anything to just inbound policy, and if applied globally it than sabotaged everything going out..
what I do like about zimbra's approach to this is that it's easy. a single command:
zmprov ms +zimbraServiceEnabled cbpolicyd
zmconfig will then spring into action on it's next invocation and rewrite the necessary postfix config to hook policyd in. if the policyd sqlite database is missing, it will indeed create it for you. you can also invoke this manually using zmcbpolicydctl - if this doesn't find the db it will create it. this is very nice. do not follow the instructions on the zextras page.
what I don't like about zimbra's approach to this is that it appears to be the usual half-baked implementation that you still have to go out and hack around by hand to get it to work effectively (think dspam, spamassassin etc). plus, they've deliberately stripped out the useful bits you need to do this (web interface). plus, any hacks put into place to get it working ala zextras way get wiped out every upgrade. the zextras wiki pages are not the best way to go about it as it tries to repair the zimbra, and let's be honest - bodging an antispam web interface into an internal zimbra apache instance meant to serve spelling on some random port, is not really the ideal situation. i'm amazed that zimbra still has this huge dependency stack just to serve spell check, surely there's a way of doing this without an entire cumbersome apache/php stack?
imho you're much better off just installing/using the proper OS apache, installing cluebringer into a more suitable place like /usr/share/cluebringer, or in your http/vhosts tree somewhere, and configuring it to point to the zimbra cb database (/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb). this then sits outside of zimbra and won't be interfered with by zimbra.
as to getting it to actually do something, i'll post back again if I get anywhere. the last time I tried to get it to greylist, it wouldn't do anything to just inbound policy, and if applied globally it than sabotaged everything going out..
CBPolicyD - Problems after Installation and setup
Hi,
Actually, I don't have any problem implementing CBPolicyD by using Zextras link. Yes, it's not an official link but I can get PolicyD to rate-limit sending messages as it should be.
Andre, I'm installing CBPolicyD on multi server scenario and using SLES Apache setup to CBPolicyD web admin. I'm using the following command to update related package :
zypper in php5-sqlite apache2 spell yast2-http-server php5-pdo
Actually, I don't have any problem implementing CBPolicyD by using Zextras link. Yes, it's not an official link but I can get PolicyD to rate-limit sending messages as it should be.
Andre, I'm installing CBPolicyD on multi server scenario and using SLES Apache setup to CBPolicyD web admin. I'm using the following command to update related package :
zypper in php5-sqlite apache2 spell yast2-http-server php5-pdo
CBPolicyD - Problems after Installation and setup
Here's how to do it on RHEL (and related systems like Fedora, CentOS etc), using a separate web server that won't get trampled by Zimbra updates.
# Activate policyd in Zimbra (refer to Postfix Policyd - Zimbra :: Wiki)
zmprov ms +zimbraServiceEnabled cbpolicyd
zmlocalconfig -e cbpolicyd_log_level=3
zmlocalconfig -e cbpolicyd_module_greylisting=1
# wait a few minutes until zimbra picks it up and activates. check with 'ps -ef |grep cbpolicy'
# Install OS Apache
yum -y install httpd php php-pdo
# Optional: Change default port of the OS Apache so it doesn't interfere with Zimbra
sed -i 's/Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf
# Install OS cluebringer (mainly for the proper webui)
yum install http://devlabs.linuxassist.net/attachme ... noarch.rpm
# In order to access this, you'll need to add your IP to the Allow directive in /etc/httpd/conf.d/cluebringer.conf.
# Personally, I just put Allow from all and then protect the port using iptables or http auth.
# Point the webui at zimbra cbpolicyd db
WEBUICONF=/etc/policyd/webui.conf
mv $WEBUICONF $WEBUICONF.orig
echo '' >$WEBUICONF
chmod 640 $WEBUICONF
chown cbpolicyd:apache $WEBUICONF
# Fire up apache
service httpd start
# Allow the webui to reach zimbra policyd db. There are various ways of doing this, all have downsides.
# I think this way is the lesser of evils
chown -R zimbra:apache /opt/zimbra/data/cbpolicyd
chmod -R 770 /opt/zimbra/data/cbpolicyd
# Point your browser at :8080/cluebringer">http://:8080/cluebringer
# Activate policyd in Zimbra (refer to Postfix Policyd - Zimbra :: Wiki)
zmprov ms +zimbraServiceEnabled cbpolicyd
zmlocalconfig -e cbpolicyd_log_level=3
zmlocalconfig -e cbpolicyd_module_greylisting=1
# wait a few minutes until zimbra picks it up and activates. check with 'ps -ef |grep cbpolicy'
# Install OS Apache
yum -y install httpd php php-pdo
# Optional: Change default port of the OS Apache so it doesn't interfere with Zimbra
sed -i 's/Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf
# Install OS cluebringer (mainly for the proper webui)
yum install http://devlabs.linuxassist.net/attachme ... noarch.rpm
# In order to access this, you'll need to add your IP to the Allow directive in /etc/httpd/conf.d/cluebringer.conf.
# Personally, I just put Allow from all and then protect the port using iptables or http auth.
# Point the webui at zimbra cbpolicyd db
WEBUICONF=/etc/policyd/webui.conf
mv $WEBUICONF $WEBUICONF.orig
echo '' >$WEBUICONF
chmod 640 $WEBUICONF
chown cbpolicyd:apache $WEBUICONF
# Fire up apache
service httpd start
# Allow the webui to reach zimbra policyd db. There are various ways of doing this, all have downsides.
# I think this way is the lesser of evils
chown -R zimbra:apache /opt/zimbra/data/cbpolicyd
chmod -R 770 /opt/zimbra/data/cbpolicyd
# Point your browser at :8080/cluebringer">http://:8080/cluebringer
CBPolicyD - Problems after Installation and setup
Getting it to actually do something is not immediately obvious, unless you're used to it. I only want greylisting - I used to use sqlgrey with Zimbra but got fed up reinstalling/reconfiguring each time I moved server or updated Zimbra. In order to greylist, you have to get round the somewhat quirky way that cbpolicyd handles profiles/groups/members/etc. For policyd dunces like myself that hit this thread and just want to do incoming greylisting, follow my instructions above to get the web interface working, then do this:
1. First, disable all main profiles except Default Inbound. While you're at it, delete the Test profile.
2. Go to Policy->Groups, select 'internal_domains' and choose 'Members' from the dropdown.
3. Delete the two example domains. Add a single email address (user@domain.com) or domain (@domain.com) that you want to test the greylisting with.
4. Re-edit the new entry and choose Disable=no (this is a common mistake to make using the web interface). It must say Disabled 'no' in order to do anything.
5. Go to Greylisting->Configure. Drop down 'Add'. Put something like this:
Name: Incoming Greylisting
Link to policy: Default Incoming
Use Greylisting: Yes
Greylist Period: 240
Track: Sender IP / 16 (needs to be this wide to start with, otherwise large providers like google will get blocked for quite a while)
Greylist Auth Validity: 604800
Greylist UnAuth Validity: 86400
Use AWL: No (you can set this later if you want, but needs bit more planning/work)
Use ABL: No (you can set this later if you want, but needs bit more planning/work)
6. Re-edit the new greylisting entry and choose Disable=no.
At this point, it should now greylist only incoming emails, only for that single address/domain that you added. Once you're happy, you can add more addresses/domains.
Keep an eye on /opt/zimbra/log/cbpolicyd.log for any errors.
Keep an eye on /var/log/zimbra.log to make sure that everything is flowing through OK, and to see what is being greylisted:
grep Grey /var/log/zimbra.log
Hope this helps policyd newbies like myself. Once it's setup it's clearly a great system and has a lot of flexibility and power outside of greylisting - I particularly like the rate limiting features. It's also great that it's now effectively built into Zimbra and can be turned on with a single command. You only need to jump through the extra hoops above if you want the web interface, for those that know what they're doing on the command line it can just be used straight away.
1. First, disable all main profiles except Default Inbound. While you're at it, delete the Test profile.
2. Go to Policy->Groups, select 'internal_domains' and choose 'Members' from the dropdown.
3. Delete the two example domains. Add a single email address (user@domain.com) or domain (@domain.com) that you want to test the greylisting with.
4. Re-edit the new entry and choose Disable=no (this is a common mistake to make using the web interface). It must say Disabled 'no' in order to do anything.
5. Go to Greylisting->Configure. Drop down 'Add'. Put something like this:
Name: Incoming Greylisting
Link to policy: Default Incoming
Use Greylisting: Yes
Greylist Period: 240
Track: Sender IP / 16 (needs to be this wide to start with, otherwise large providers like google will get blocked for quite a while)
Greylist Auth Validity: 604800
Greylist UnAuth Validity: 86400
Use AWL: No (you can set this later if you want, but needs bit more planning/work)
Use ABL: No (you can set this later if you want, but needs bit more planning/work)
6. Re-edit the new greylisting entry and choose Disable=no.
At this point, it should now greylist only incoming emails, only for that single address/domain that you added. Once you're happy, you can add more addresses/domains.
Keep an eye on /opt/zimbra/log/cbpolicyd.log for any errors.
Keep an eye on /var/log/zimbra.log to make sure that everything is flowing through OK, and to see what is being greylisted:
grep Grey /var/log/zimbra.log
Hope this helps policyd newbies like myself. Once it's setup it's clearly a great system and has a lot of flexibility and power outside of greylisting - I particularly like the rate limiting features. It's also great that it's now effectively built into Zimbra and can be turned on with a single command. You only need to jump through the extra hoops above if you want the web interface, for those that know what they're doing on the command line it can just be used straight away.