I installed openldap 2.4.35 from source tarball with berkeleydb 5.0.32.NC on CentSO 6.4 x86_64.
After running a few days , the ldap server shutdown unexpectedly. And here is the last log:
ber_get_next
TLS trace: SSL3 alert read:warning:close notify
52b7b798 ber_get_next on fd 13 failed errno=0 (Success)
52b7b798 conn=1023 op=70 do_unbind
52b7b798 connection_close: conn=1023 sd=13
TLS trace: SSL3 alert write:warning:close notify
52b7cbba daemon: shutdown requested and initiated.
52b7cbba slapd shutdown: waiting for 0 operations/tasks to finish
52b7cbba slapd shutdown: initiated
52b7cbba ====> bdb_cache_release_all
52b7cbba slapd destroy: freeing system resources.
52b7cbba slapd stopped.
The configuration file (slapd.conf):
include /home/ucportal/local/openldap/etc/openldap/schema/core.schema
include /home/ucportal/local/openldap/etc/openldap/schema/corba.schema
include /home/ucportal/local/openldap/etc/openldap/schema/cosine.schema
include /home/ucportal/local/openldap/etc/openldap/schema/duaconf.schema
include /home/ucportal/local/openldap/etc/openldap/schema/dyngroup.schema
include /home/ucportal/local/openldap/etc/openldap/schema/inetorgperson.schema
include /home/ucportal/local/openldap/etc/openldap/schema/java.schema
include /home/ucportal/local/openldap/etc/openldap/schema/misc.schema
include /home/ucportal/local/openldap/etc/openldap/schema/nis.schema
include /home/ucportal/local/openldap/etc/openldap/schema/openldap.schema
include /home/ucportal/local/openldap/etc/openldap/schema/ppolicy.schema
include /home/ucportal/local/openldap/etc/openldap/schema/collective.schema
include /home/ucportal/local/openldap/etc/openldap/schema/uc.schema
pidfile /home/ucportal/local/openldap/var/run/slapd.pid
argsfile /home/ucportal/local/openldap/var/run/slapd.args
loglevel 1
logfile /home/ucportal/openldap/var/log/slapd.log
database bdb
suffix "dc=ucweb,dc=com"
rootdn "cn=admin,dc=ucweb,dc=com"
rootpw 123456
directory /home/ucportal/local/openldap/var/openldap-data
index objectClass eq
index entryUUID,entryCSN eq
TLSCACertificateFile /home/ucportal/openldap/etc/openldap/cacerts/ca.crt
TLSCertificateFile /home/ucportal/openldap/etc/openldap/ldap-server.crt
TLSCertificateKeyFile /home/ucportal/openldap/etc/openldap/ldap-key.pem
Attention : I installed and run openldap with non-root user
I used this command to start ldap daemon process: slapd -f ~/openldap/etc/openldap/slapd.conf -d 1 -h 'ldaps://0.0.0.0:6361'
Any suggestions?
This is a very common issue with Open-LDAP servers, firstly I'll recommend you to migrate this question to serverfault. This will be a good practice to always run your daemons with root priviledges.
Based on my so far research I'd like to share these links with you, I hope they may help you to fix your problems.
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,10/func,view/id,19945/
http://www.openldap.org/lists/openldap-software/200502/msg00268.html
Configure OpenLDAP
https://serverfault.com/questions/138286/configuring-openldap-and-ssl
http://www.openldap.org/doc/admin24/slapdconf2.html
Related
I have Alpine Linux, 3.15.0 version on the server.
The installed nginx version is 1.21.6. I have performed apk update
nginx -t command successfully responds with
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
When I type nginx -s reload server responds with
2023/02/03 10:58:00 [notice] 54#54: signal process started
but nothing actually happens. It's like the process started and that's all.
What am I missing?
According to Nginx documentation, command nginx -s reload actually sends signal to nginx master process and
once the master process receives the signal to reload configuration,
it checks the syntax validity of the new configuration file and tries
to apply the configuration provided in it. If this is a success, the
master process starts new worker processes and sends messages to old
worker processes, requesting them to shut down.
Thus, we can consider that nginx is restarted (If we disregard the fact that the master process itself continued to work).
At the same time, if you want to totally restart nginx, you can stop it with nginx -s quit command and then start again. Or that's much better use your system service manager. If I'm not mistaken, there is an open-rc in Alpine, thus command will be rc-service nginx restart.
I am getting this error in my nginx-error.log file:
2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "EC2.amazonaws.com"
The browser also shows a 502 Bad Gateway Error. The output of a curl is the same, Bad Gateway html
I've tried to fix it by changing permissions for /tmp/uwsgi.sock to 777. That didn't work. I also added myself to the www-data group (a couple questions that looked similar suggested that). Also, no dice.
Here is my nginx.conf file:
nginx.conf
worker_processes 1;
worker_rlimit_nofile 8192;
events {
worker_connections 3000;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
I am running a Flask application with Nginsx and Uwsgi, just to be thorough in my explanation. If anyone has any ideas, I would really appreciate them.
EDIT
I have been asked to provide my uwsgi config file. So, I never personally wrote my nginx or my uwsgi file. I followed the guide here which sets everything up using ansible-playbook. The nginx.conf file was generated automatically, but there was nothing in /etc/uwsgi except a README file in both apps-enabled and apps-available folders. Do I need to create my own config file for uwsgi? I was under the impression that ansible took care of all of those things.
I believe that ansible-playbook figured out my uwsgi configuration since when I run this command
uwsgi -s /tmp/uwsgi.sock -w my_app:app
it starts up and outputs this:
*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09) [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts.
The correct way to solve the problem is to make uwsgi change the ownership and/or permission of /tmp/uwsgi.sock such that nginx can write to this socket. Therefore, there are three possible solutions.
Run uwsgi as the www-data user so that this user owns the socket file created by it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
Change the ownership of the socket file so that www-data owns it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
Change the permissions of the socket file, so that www-data can write to it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
I prefer the first approach because it does not leave uwsgi running as root.
The first two commands need to be run as root user. The third command does not need to be run as root user.
The first command leaves uwsgi running as www-data user. The second and third commands leave uwsgi running as the actual user that ran the command.
The first and second command allow only www-data user to write to the socket. The third command allows any user to write to the socket.
I prefer the first approach because it does not leave uwsgi running as root user and it does not make the socket file world-writeable .
While the accepted solution is true there might also SELinux be blocking the access. If you did set the permissions correctly and still get permission denied messages try:
sudo setenforce Permissive
If it works then SELinux was at fault - or rather was working as expected! To add the permissions needed to nginx do:
# to see what permissions are needed.
sudo grep nginx /var/log/audit/audit.log | audit2allow
# to create a nginx.pp policy file
sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# to apply the new policy
sudo semodule -i nginx.pp
After that reset the SELinux Policy to Enforcing with:
sudo setenforce Enforcing
Anyone who lands here from the Googles and is trying to run Flask on AWS using the default Ubuntu image after installing nginx and still can't figure out what the problem is:
Nginx runs as user "www-data" by default, but the most common Flask WSGI tutorial from Digital Ocean has you use the logged in user for the systemd service file. Change the user that nginx is running as from "www-data" (which is the default) to "ubuntu" in /etc/nginx/nginx.conf if your Flask/wsgi user is "ubuntu" and everything will start working. You can do this with one line in a script:
sudo sed -i 's/user www-data;/user ubuntu;/' /etc/nginx/nginx.conf
Trying to make Flask and uwsgi run as www-data did not work off the bat, but making nginx run as ubuntu worked just fine since all I'm running with this instance is Flask anyhow.
You have to set these permissions (chmod/chown) in uWSGI configuration.
It is the chmod-socket and the chown-socket.
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket
Nginx connect to .sock failed (13:Permission denied) - 502 bad gateway
change the name of the user on the first line in /etc/nginx/nginx.conf file.
the default user is www-data and change it to root or your username
I know it's too late, but it might helps to other. I'll suggest to follow Running flask with virtualenv, uwsgi, and nginx very simple and sweet documentation.
Must activate your environment if you run your project in virtualenv.
here is the yolo.py
from config import application
if __name__ == "__main__":
application.run(host='127.0.0.1')
And create uwsgi.sock file in /tmp/ directory and leave it blank.
As #susanpal answer said "The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts." it is correct.
So you have to give permission to sock file whenever uwsgi starts.
so now follow the below command
uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666
A little different command from #susanpal.
And for persist connection, simply add "&" end of command
uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
In my case changing some php permission do the trick
sudo chown user:group -R /run/php
I hope this helps someone.
You should post both nginx and uwsgi configuration file for your application (the ones in /etc/nginx/sites-enabled/ and /etc/uwsgi/ - or wherever you put them).
Typically check that you have a line similar to the following one in your nginx app configuration:
uwsgi_pass unix:///tmp/uwsgi.sock;
and the same socket name in your uwsgi config file:
socket=/tmp/uwsgi.sock
I want to make a backup for my remote server folders(ubunto server)to another remote sever (Linux server). but once I run this command from the the first server it dispalys me an error message:
rsync -raz --progress firstdirectoy root#serverIP:/home
The displayed messahe is:
ssh: connect to host <serverIP> port 22: Connection timed out
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
But the same command from the server 2 to the server 1 works fine and the folder is nicely copyed into the server1.
How can I escape the connexion error in order to copy my folder from server 1 to server 2 throw rsync?
Seems like server2 has no active ssh daemon while server1 has.
Try to run ssh daemon or use raw rsync protocol and rsync daemon.
If it's a connection timeout because your SSH server is slow to respond, you can tweak the timeout in rsync:
rsync -e 'ssh -o ConnectTimeout=120'
Else it may be a missing SSH daemon (sshd) on server 2 as stated by #geov, or a closed port on your firewall. You may start by testing an SSH login:
ssh user#serverIP
And see if it's working or not. Probably nmap serverIP will help you too, stating if SSH is running or not.
And please do NOT use root user for your rsync copy!
if you wait for a long time, the prompt appears
I think that your server2's IP is wrong
For me, this error appeared when attempting to rsync between two AWS EC2 instances where the two instances were not a part of the same security group.
Overview of how to create security groups
How to change the security groups of the instances
Allow instances within the same security group to communicate
I have created a flask app and up to this point have been using the default flask server for creating/testing it. Now i want to deploy it to a server. I am using uwsgi and nginx, though i am pretty new to both. i know there are a lot of guides and questions about similar things, but i couldnt find the solution after looking through as much as i could understand
The following is from my uwsgi log :
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ben/flask/MLS-Flask
detected binary path: /home/ben/flask/MLS-Flask/mls-flask-ve/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 1024
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /home/ben/flask/MLS-Flask/mls_uwsgi.sock fd 3
Python version: 3.3.3 (default, Dec 30 2013, 16:29:41) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
Set PythonHome to /home/ben/flask/MLS-Flask/mls-flask-ve
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x11755d0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
added /home/ben/flask/MLS-Flask/ to pythonpath.
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x11755d0 pid: 2926 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 2926, cores: 1)
I am assuming the uwsgi is at least running? I am fairly new to this so i am not quite sure that the problem is.
my nginx config is :
server{
listen 8080;
charset utf-8;
location / {try_files $uri #app; }
location #app {
include uwsgi_params;
uwsgi_pass unix:/home/ben/flask/MLS-Flask/mls_uwsgi.sock;
}
}
my uwsgi ini is :
[uwsgi]
uid = nginx
gid = nginx
base = /home/ben/flask/MLS-Flask
home = %(base)/mls-flask-ve
pythonpath = %(base)
chdir = /home/ben/flask/MLS-Flask
module = runp
#socket file's location
socket = /home/ben/flask/MLS-Flask/mls_uwsgi.sock
#permissions for the socket file
chmod-socket = 666
#variable that holds a flask application inside the module imported
callable = app
#location of log file
logto = /var/log/uwsgi/%n.log
and the file the uwsgi ini is running is my flask app:
from app import app
if __name__ == "__main__":
app.run(debug = False, port = 8080)
I may have some extraneous stuff in my uwsgi ini or nginx config, but i am not sure if those would necessarily be the problems. Can anyone see any reasons why this might not be working? I am currently getting a 502 bad gateway error on localhost:8080, so i am guessing it has something to do with my flask, uwsgi ini/socket.
i appreciate any help.
It turned out my nginx user didnt have access to the socket because the / and /home/ directory was owned by the root group and root user. I ended up giving full access to the owner and group all the way from / directory to the socket (this probably is not the safest solution security wise, but i can further refine it after i get everything working.)
I had the same problem :
Always check socket permissions by using ls -lhtr
Try putting socket in /run/myapp/mysock.sock folder
Create an empty sock file in this folder vi mysock.sock
Set permissions of this empty file to have full access by your user and group stated
in the service. chown user:group /run/myapp/mysock.sock
I am am currently running OpenLdap 2.4.31 on Ubuntu 12.04 in EC2. I am having an issue where I get random timeouts when doing ldapsearch or ldapadd commands against the ldap server.
There is really no load against the ldap servers, I am using them for name resolution for EC2 internal hostnames and using ldap as an external node classifier for puppet.
When the timeout happens I get the following error:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server
If I rerun the command it works fine, this is causing some issues in my automation (and while I can put in error checking for this it seems odd its happening in the first place).
Here is a copy of my slapd.conf (with some env specific info commented out) hopefully someone has some suggestions on what I am missing in the config to prevent the timeout issue:
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/core.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/collective.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/corba.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/cosine.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/duaconf.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/dyngroup.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/inetorgperson.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/java.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/misc.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/nis.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/openldap.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/ppolicy.schema
include /opt/openldap/openldap-2.4.31/etc/openldap/schema/puppet.schema
pidfile /opt/openldap/openldap-2.4.31/var/run/slapd.pid
argsfile /opt/openldap/openldap-2.4.31/var/run/slapd.args
loglevel 0
serverID 001
database bdb
suffix "dc=example,dc=local"
rootdn "cn=admin,dc=example,dc=local"
rootpw secret
directory /opt/openldap/openldap-2.4.31/var/openldap-data
idletimeout 120
timelimit 300
cachesize 2000
syncrepl rid=000
provider=ldap://10.10.10.10
type=refreshAndPersist
retry="5 5 10 +"
searchbase="dc=example,dc=local"
attrs="*,+"
bindmethod=simple
binddn="cn=admin,dc=example,dc=local"
credentials=secret
syncrepl rid=000
provider=ldap://10.10.10.20
type=refreshAndPersist
retry="5 5 10 +"
searchbase="dc=example,dc=local"
attrs="*,+"
bindmethod=simple
binddn="cn=admin,dc=example,dc=local"
credentials=secret
index entryCSN eq
index entryUUID eq
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
Ignore this question. My self-healing automation was misconfiguration and was restarting the slapd process every minute on accident.