Woe is me! I have to deal with good ol' OpenLDAP. I have installed OpenLDAP by installing RPMs openldap-servers, openldap and openldap-clients. I want to change the olcSuffix from the default:
olcSuffix: dc=my-domain,dc=com
To my real domain. So I created this file, ex.ldif:
# pwd
/etc/openldap
# cat ex.ldif
dn: olcDatabase{2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com
Then I execute:
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ex.ldif
But I get this error message:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={2}hdb,cn=config"
ldap_modify: Other (e.g. implementation specific) error (80)
And nothing is updated in my /etc/openldap/slapd.d configs.
I disabled selinux and the problem went away.
Related
I have an ubuntu server running openldap to connect to our phones.
A while back I set this to use ldaps with letsencrypt which has worked fine with most things until recently they made a change ref the X3 cert. I am unable to install a late enough version so I can run the --preferred-chain "ISRG ROOT X1 and can't use the snap version as the box ix on lcx and wont run it.
The company has now bought a digi cert wild card certificate and would like this to be on the ldap server, but I can't get it to load the config
The original ldif file I created to import is below with the domain name changed.
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/letsencrypt/live/directory.mydomain.co.uk/fullchain.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/letsencrypt/live/test-directory.mydomain.co.uk/cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/letsencrypt/live/test-directory.mydomain.co.uk/privkey.pem
I have tried to change the file with modify commands and it's just wont have it and seem to keep getting the below.
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Inappropriate matching (18)
additional info: modify/add: olcTLSCACertificateFile: no equality matching rule
Any advise here would be great thanks.
I propose to check the contents of the ldif for special not intended characters. Like: $sudo cat -tve *.ldif?
Older Versions of Contao (till 4.3) working like expected with sending emails via sendmail.
After upgrade to Contao 4.9 I got some errors at Providers like 1u1 / ionos or mittwald.
The error in the logs sound like:
"Expected response code 220 but got an empty response"
Sending Mails from CLI of the Server (means if logged in via SSH) working like expected:sendmail test" |
/usr/sbin/sendmail -t -v -f sender#domain.com reciepient#otherOne.com
The solution is to add this to config/config.yml
swiftmailer:
default_mailer: default
mailers:
default:
url: '%env(MAILER_URL)%'
transport: sendmail
command: '/usr/sbin/sendmail -t -i'
After that, clear the Contao-Cache (e.g. via contao-manager.phar) and give it a try.
The reason for that issue is, that by default the swiftMailer use sendmail -bs as command, which means that sendmail run as standalone Service.
Depending at the way your provider configure it's sendmail, this will be the cause of the error.
If you update symfony/swiftmailer-bundle to version 3.5.0, then the default value used for the sendmail command will be read from the PHP configuration. See https://github.com/symfony/swiftmailer-bundle/pull/302
So provided the PHP configuration of your hosting environment contains the correct command in sendmail_path, sending emails should work without any changes.
Is there any way to suppress these log messages in Symfony 4:
cache.WARNING: Failed to save key "%5B%5BC%5DApp%5CController%5CAgencyController%23about%5D%5B1%5D" '(integer) {"key":"%5B%5BC%5DApp%5CController%5CAgencyController%23about%5D%5B1%5D","type":"integer","exception":"[object] (ErrorException(code: 0): touch(): Utime failed: Operation not permitted at /mnt/c/Users/...../vendor/symfony/cache/Traits/FilesystemCommonTrait.php:95)"} []
There are hundredes of them in log (monolog) per each request which is really annoying! I have tried to change permissions to 777 as similar question answers suggested but that does no effect (maybe since I'm on WSL). Also I do not have APC installed.
Are you sure you are using php 7+? Seems like the file your are accessing in a windows filesystem. touch() will fail with php 5.4 (or 5.3 don't remember) on windows filesystems. Also, try changing your cache files owner, (not just 777) wo they are owned by your webserver user. sudo chown -R user:usergroup directory/
Are you using vagrant?
I answered the same here
I had the same problem.
All you need to do is change the type of the synced_folder to nfs, but that option only works with Mac hosts.
To be able to use it in Windows, you need to install vagrant-winnfsd
$ vagrant plugin install vagrant-winnfsd
Then change the type of the synchronisation in your Vagrantfile
Vagrant.configure("2") do |config|
config.vm.synced_folder ".", "/var/www", type: "nfs"
end
The documentation says that it is also needed to change the type of the network to dhcp, but I didn't need to do that to solve my problem.
config.vm.network "private_network", type: "dhcp"
I hope this helped
I am new to salt-ssh and I have gotten it to work successfully for setting up a remote system. However, I have a login issue that I don't know how to address. What is happening is that when I try to run the salt-ssh commands I have to fight with then initial login process before eventually it just works. I am looking to see if I can narrow down what is causing me to have to fight with login process.
I am using OS X to run my salt-ssh commands against an ubuntu vagrant vm.
I have added my root user's ssh key to the root user authorized_keys on the vagrant vm. I have verified that I can log into the system using ssh without any issues
sudo ssh root#192.168.33.10
Here are what my config files look like:
roster
managed:
host: 192.168.33.10
user: root
sudo: true
Saltfile
salt-ssh:
config_dir: /users/vmcilwain/projects/salt-ssh-rails
roster_file: /users/vmcilwain/projects/salt-ssh-rails/roster
log_file: /users/vmcilwain/projects/salt-ssh-rails/saltlog.txt
master
file_roots:
base:
- /users/vmcilwain/projects/salt-ssh-rails/states
pillar_roots:
base:
- /users/vmcilwain/projects/salt-ssh-rails/pillars
I run this command:
sudo salt-ssh -i '*' test.ping
I enter my local user's password and I get this output
Permission denied for host 192.168.33.10, do you want to deploy the salt-ssh key? (password required):
[Y/n]
This is where my fight is. If the vagrant vm has the ssh key for the user I am executing salt-ssh as, why am I being told that permission is denied? Especially when I verified I could ssh into the system without using salt-ssh.
Clicking yes prompts me for the remote root user's password, which I didn't set and don't necessarily want to since an ssh key should have worked.
I'm hoping someone can tell me the best way to setup connections between both systems so that I don't have to have this fight every time.
I needed to set the priv in my roster to the rsa key that I am using to connect to the remote host:
priv: /Users/vmcilwain/.ssh/id_rsa
I have searched several posting on this message and I am still getting the error when I attempt to do an "ldapsearch"
I have changed the slapd.conf to use a plain-text password and I am still getting the error. I have also made sure that there are no blank spaces in the file. The log file shows and iptables is turned off. I have attempted to follow the LDAP setup from
"http://www.itmanx.com/kb/centos63-openldap-phpldapadmin".
conn=1001 fd=15 ACCEPT from IP=[::1]:54486 (IP=[::]:389)
conn=1001 op=0 BIND dn="cn=Manager,dc=domain,dc=local,dc=pt" method=128
conn=1001 op=0 RESULT tag=97 err=49 text=
conn=1001 fd=15 closed (connection lost)
my server is running Centos 6.4 64.
below are the commands I am using
"ldapsearch -x -D cn=Manager,dc=domain,dc=local,dc=pt -w abc"
my slapd.conf file
database bdb
suffix "dc=domain,dc=local"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=local"
rootpw abc
You need to generate your password like below -
slappasswd -h {CLEARTEXT}
enter password - abc
Do the search -
ldapsearch -x -h ipaddress(mention ip address) -D "cn=Manager,dc=domain,dc=local" -W
In the search you try to bind as:
cn=Manager,dc=domain,dc=local,dc=pt
but in the config the rootdn is:
cn=Manager,dc=domain,dc=local
This is of course "an invalid credential".
You are binding as the rootdn, which is to say the "root account" of your DIT. This account's password is, in this case, config-based. It is possible that while 'abc' is the configured password, it may not be the loaded password.
Case in point: Someone goes into the slapd.conf file and changes the rootdn password from 'xyz' to 'abc' but neglects to restart the OpenLDAP daemon. What will happen here is that 'abc' will NOT work until the process is restarted, and thus the OpenLDAP daemon will continue to honor the OLD password of 'xyz'.
I hope this helps...
Max