At first I am really surprised about your very fast response. Really really thank's. And congratule for your work with Kolab/Gentoo.
hm that looks like several things are broken at the same time. I will suggest a few actions and checks:
1) Once you run "kolabconf" check your syslog for errors. If kolabconf hits an error while writing a configuration it will abort and fail to write any subsequent configurations.
Done, the only two messages given into /var/log/everything/current (metalog) are:
Jan 15 15:30:32 [kolabconf] T Error: Error moving configfile to /var/www/kolab/htdocs/horde/ingo/config/conf.php, error: No such file or directory_
Jan 15 15:30:32 [kolabconf] T Error: Unable to change permissions of `/var/www/kolab/htdocs/horde/ingo/config/conf.php' to 0600_
Seems to be a missing file, probably because the package is masked at this time.
No more errors... running kolabconf using debug mode (kolabconf -d) shows me that. The passwords and the domain are hidden.
apache-allow-unauthenticated-fb : FALSE
apache-http : TRUE
base_dn : dc=domain,dc=org
bind_dn : cn=manager,cn=internal,dc=domain,dc=org
bind_pw : HIDDEN
bind_pw_hash : {SSHA}HIDDEN
calendar_dn : cn=calendar,cn=internal,dc=domain,dc=org
calendar_pw : HIDDEN
conn_refresh_period : 60
cyrus-admins : manager
cyrus-autocreatequota : 100000
cyrus-imap : TRUE
cyrus-imaps : TRUE
cyrus-pop3 : FALSE
cyrus-pop3s : TRUE
cyrus-quotawarn : 80
cyrus-sieve : TRUE
cyrus_admin : manager
cyrus_admin_pw : HIDDEN
directory_mode : slurpd
dirserv_home_server : main
dirserv_mailbox_password :
dirserv_mailbox_server :
dirserv_mailbox_user :
dirserv_poll_period : 120
fqdn : main
fqdnhostname : domain.org
group_bind_dn : cn=manager,cn=internal,dc=domain,dc=org
group_bind_pw : HIDDEN
group_directory_mode : slurpd
group_dn_list : dc=domain,dc=org
group_field_deleted : kolabdeleteflag
group_field_guid : entryUUID
group_field_modified : modifytimestamp
group_ldap_ip : 127.0.0.1
group_ldap_port : 389
group_ldap_uri : ldap://127.0.0.1:389
group_object_class : kolabgroupofnames
gyard_deletion_period : 10080
is_master : true
k : kolab
kolab_dn : k=kolab,dc=domain,dc=org
kolab_gid : 442
kolab_n_gid : 444
kolab_n_uid : 106
kolab_r_gid : 443
kolab_r_uid : 105
kolab_uid : 104
kolabhost : domain.org
ldap_ip : 127.0.0.1
ldap_master_uri : ldap://127.0.0.1:389
ldap_port : 389
ldap_uri : ldap://127.0.0.1:389
log_level : 2
maildefer_header :
maildefer_listen : 127.0.0.1:10024
maildefer_size :
maildefer_talk : 127.0.0.1:10025
objectclass : top, kolab
php_dn : cn=nobody,cn=internal,dc=domain,dc=org
php_pw : HIDDEN
postfix-allow-unauthenticated : TRUE
postfix-enable-virus-scan : TRUE
postfix-mydestination : domain.org
postfix-mydomain : domain.org
postfix-mynetworks : 127.0.0.0/8
prefix : /
proftpd-ftp : FALSE
proftpd-userPassword :
sf_bind_dn : cn=manager,cn=internal,dc=domain,dc=org
sf_bind_pw : HIDDEN
sf_directory_mode : slurpd
sf_dn_list : dc=domain,dc=org
sf_field_deleted : kolabdeleteflag
sf_field_guid : entryUUID
sf_field_modified : modifytimestamp
sf_field_quota : cyrus-userquota
sf_ldap_ip : 127.0.0.1
sf_ldap_port : 389
sf_ldap_uri : ldap://127.0.0.1:389
sf_object_class : kolabsharedfolder
slurpd_accept_addr : 127.0.0.1
slurpd_addr : 127.0.0.1
slurpd_port : 9999
uid : freebusy
userPassword : freebusy
user_bind_dn : cn=manager,cn=internal,dc=domain,dc=org
user_bind_pw : HIDDEN
user_directory_mode : slurpd
user_dn_list : dc=domain,dc=org
user_field_deleted : kolabdeleteflag
user_field_guid : entryUUID
user_field_modified : modifytimestamp
user_field_quota : cyrus-userquota
user_ldap_ip : 127.0.0.1
user_ldap_port : 389
user_ldap_uri : ldap://127.0.0.1:389
user_object_class : inetOrgPerson
userpassword : freebusy
Excuse the long paste...
2) You definitely need to turn on "Accept mail from other domains over non-authenticated SMTP". If this is enabled but you still get a "Relay Access Denied" then the user you try to authenticate with is not recognized as being a member of the domains postfix is serving. Did you recreate the virtual domains your sever should handle after removing the LDAP db?
I have this option turned on, but I'm not sure if its aplied into prostfix configuration (I supos that kolabconf do that). However the user and mail accoun seems to exists into database as can be checked using testsaslauth:
main ~ # testsaslauthd -u nulluser@domain.org -p HIDDEN
0: OK "Success."
main ~ # testsaslauthd -u unexist@domain.org -p HIDDEN
0: NO "authentication failed"
I have created the user using web interface :/
Btw, look at this from postfix configuration...
main ~ # cat /etc/postfix/main.cf | grep sasl
main ~ # cat /etc/kolab/templates/main.cf.template | grep sasl
permit_sasl_authenticated,
smtpd_sasl_auth_enable = yes
#smtpd_sasl_local_domain = $myhostname
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
As you can see the template has info about sasl, but not the real configuration file. kolabconf seem to ignore it :-?
In using mail-mta/postfix 2.2.10-r20 with that flags; USE="ipv6 kolab ldap mailwrapper mysql pam sasl ssl -hardened -mbox -nis -postgres (-selinux) -vda"
3) The reason why some packages are masked is because they are still under development and can break at any time. But to be honest they are probably the ones most likely to work without problems, too. The overlay structure is currently suboptimal. This should change with the Kolab-2.1 release which now is not too far off. But it would be good if I find the time to document the current overlay structure a little bit better.
I'll try to use masked pakages when Kolab base works fine and will tell you my feedback
We are waiting for Kolab-2.1, I can try to help the project testing pakages If you need it (im using kolab for my friend's group, not into a company or critical systems).
