I have installed opensips-2.1.2 in on vmware (ubuntu 14.4.6).
I can see opensips installation went fine, but not able to access the web interface for the same.
After installation i have greped the process to confirm if it got installed or not, it looks fine from here
opensips 19881 3641 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19882 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19883 19881 0 11:42 ? 00:00:05 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19884 19881 0 11:42 ? 00:00:01 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19885 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19886 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19887 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19888 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
root 23310 4465 0 12:05 pts/4 00:00:00 grep --color=auto opensips```
Please help me, what is blocking me to access the same on web interface.
Installing the "opensips-2.1.2" package will only provide the OpenSIPS SIP server, which will process the incoming SIP traffic.
The OpenSIPS Control Panel is a separate project, meant to be accessed via a web server, such as Apache or Nginx. Its purpose is to help system administrators provision various data for OpenSIPS to work with. See the available install options here.
Related
I've upgraded my varnish from 6.2.x to 6.6.x. Amost everyting works Ok, but no reload.
After "start" ps show:
root 10919 0.0 0.0 18960 5288 ? Ss 22:38 0:00 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
now I try to reload:
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd auth 0124ef9602b9e6aad2766e52755d02a0d17cd6cfe766304761d21ea058bd8b3b
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Wr 200 -----------------------------#012Varnish Cache CLI 1.0#012-----------------------------#012Linux,5.4.0-107-generic,x86_64,-junix,-smalloc,-sfile,-sdefa
ult,-hcritbit#012varnish-6.6.1 revision e6a8c860944c4f6a7e1af9f40674ea78bbdcdc66#012#012Type 'help' for command list.#012Type 'quit' to close CLI session.
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd ping
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Wr 200 PONG 1649450530 1.0
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd vcl.load reload_20220408_204210_11818 /etc/varnish/default.vcl
Apr 8 22:42:15 xxx varnishreload[11818]: VCL 'reload_20220408_204210_11818' compiled
Apr 8 22:42:20 xxx varnishreload[11818]: Command: varnishadm -n '' -- vcl.use reload_20220408_204210_11818
Apr 8 22:42:20 xxx varnishreload[11818]: Rejected 400
Apr 8 22:42:20 xxx varnishreload[11818]: CLI communication error (hdr)
Apr 8 22:42:20 xxx systemd[1]: varnish.service: Control process exited, code=exited, status=1/FAILURE
Apr 8 22:42:20 xxx systemd[1]: Reload failed for Varnish Cache, a high-performance HTTP accelerator.
and now ps shows:
vcache 10919 0.0 0.0 19048 5880 ? SLs 22:38 0:00 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
vcache 10959 0.4 0.2 84585576 23088 ? SLl 22:39 0:01 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
I see process owner was changed to vcache. What is wrong with it? anoder reload will fail too with same reject code.
Can you try removing -j unix,user=vcache from your varnishd runtime command. If I remember correctly, Varnish will automatically drop privileges on the worker process without really needing to explicitly set jailing settings.
If that doesn't work, please also explain which commands you used to start Varnish and reload Varnish.
I'm trying to get memory metric from client machine. I installed nrpe in client machine and works well for default checks like load, users and all.
Manual output from client machine,
root#Nginx:~# /usr/lib/nagios/plugins/check_mem -w 50 -c 40
OK - 7199 MB (96%) Free Memory
But when i try from server, other metrics works but memory metrics not working,
[ec2-user#ip-10-0-2-179 ~]$ /usr/lib64/nagios/plugins/check_nrpe -H 107.XX.XX.XX -c check_mem
NRPE: Unable to read output
Other metrics works well
[ec2-user#ip-10-0-2-179 ~]$ /usr/lib64/nagios/plugins/check_nrpe -H 107.XX.XX.XX -c check_load
OK - load average: 0.00, 0.01, 0.05|load1=0.000;15.000;30.000;0; load5=0.010;10.000;25.000;0; load15=0.050;5.000;20.000;0;
I ensured that check_mem command has execution permission for all,
root#Nginx:~# ll /usr/lib/nagios/plugins/check_mem
-rwxr-xr-x 1 root root 2394 Sep 6 00:00 /usr/lib/nagios/plugins/check_mem*
Also here is my client side nrpe config commands
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_procs]=/usr/lib/nagios/plugins/check_procs -w 200 -c 250
command[check_http]=/usr/lib/nagios/plugins/check_http -I 127.0.0.1
command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 30 -c 20
command[check_mem]=/usr/lib/nagios/plugins/check_mem -w 30 -c 20
Can anyone help me to fix the issue?
We had shiny server running on an i686 machine under Ubuntu 16.04. After a recent upgrade server does not run the apps we were using to read and plot data from a MySQL database.
Now when we try to connect to our server the shiny app appears but in 1-2 seconds the screen goes to grey and a disconnected from server message appears
As there are no precompiled binaries for our system we have followed instructions to build from source at Rstudio github site. It apparently runs fine.
Shiny process is up and running
ps -ef | grep shiny
root 13596 1 0 10:19 ? 00:00:01 /usr/local/shiny-server/ext/node/bin/shiny-server /usr/local/shiny-server/lib/main.js --pidfile=/var/run/shiny-server.pid
status shiny-server
shiny-server start/running, process 13596
But at /var/log/shiny-server.log this error message appears
[2016-12-09 09:39:18.692][ERROR] shiny-server - Error getting worker: TypeError driver.validateOptions is not a function
Any idea of what happens with our server? Thanks in advance
Machine info:
uname -a Linux rack4tb 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26
19:39:59 UTC 2016 i686 i686 i686 GNU/Linux
EDIT
Add output from history > serverHistory.txt
meteo#rack4tb:~$ tail -n 50 serverHistory.txt
1952 $PYTHON --version
1953 cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DPYTHON="$PYTHON" ../
1954 shiny-server-1.4.2.0
1955 make
1956 mkdir ../build
1957 (cd .. && ./bin/npm --python="$PYTHON" install)
1958 (cd .. && ./bin/node ./ext/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js --python="$PYTHON" rebuild)
1959 sudo make install
1960 sudo ln -s /usr/local/shiny-server/bin/shiny-server /usr/bin/shiny-server
1961 ls -l /usr/local/shiny-server/bin/shiny-server
1962 ls -l /usr/bin/shiny-server
1963 rm /usr/bin/shiny-server
1964 sudo rm /usr/bin/shiny-server
1965 sudo ln -s /usr/local/shiny-server/bin/shiny-server /usr/bin/shiny-server
1966 sudo useradd -r -m shiny
1967 sudo mkdir -p /var/log/shiny-server
1968 sudo mkdir -p /srv/shiny-server
1969 sudo mkdir -p /var/lib/shiny-server
1970 sudo chown shiny /var/log/shiny-server
1971 sudo mkdir -p /etc/shiny-server
1972 cat /var/log/shiny-server
1973 cd /var/log/shiny-server
1974 ls -lrt
1975 cd ..
1976 ls
1977 ls -lrt
1978 cat shiny-server.log
1979 /etc/mysql$ shiny-server --version
1980 /etc/mysql shiny-server --version
1981 shiny-server --version
1982 uname -m
1983 uname -a
1984 ps -ef | grep shiny
1985 sudo status shiny-server
1986 status shiny-server
1987 exit
1988 cd /usr/local
1989 ls
1990 ls shiny-server/
1991 ls shiny-server/bin
1992 ls shiny-server/R
1993 cat shiny-server/VERSION
1994 cd
1995 ls
1996 ls Descargas/
1997 ls
1998 ls shiny-server*deb
1999 rm shiny-server*deb
2000 exit
2001 history > serverHistory.txt
What worked for me was to launch sudo R and install all packages the app needs:
sudo su - -c "R -e \"install.packages('package_name', repos = 'http://cran.rstudio.com/',dependencies =TRUE)\""
I created a database "my_new_database" and "albums", neither of which I can DELETE. I believe I am still in "ADMIN" party mode. To demonstrate my issue Ill just post some info below.
First here is to show couchdb running ( started using the SystemV script via service )
$ ps aux | grep couch
couchdb 2939 0.0 0.2 108320 1528 ? S 20:45 0:00 /bin/sh -e /usr/bin/couchdb -a /etc/couchdb/default.ini -a /etc/couchdb/local.ini -b -r 0 -p /var/run/couchdb/couchdb.pid -o /dev/null -e /dev/null -R
couchdb 2950 0.0 0.1 108320 732 ? S 20:45 0:00 /bin/sh -e /usr/bin/couchdb -a /etc/couchdb/default.ini -a /etc/couchdb/local.ini -b -r 0 -p /var/run/couchdb/couchdb.pid -o /dev/null -e /dev/null -R
couchdb 2951 4.8 2.3 362168 14004 ? Sl 20:45 0:00 /usr/lib64/erlang/erts-5.8.5/bin/beam -Bd -K true -A 4 -- -root /usr/lib64/erlang -progname erl -- -home /usr/local/var/lib/couchdb -- -noshell -noinput -sasl errlog_type error -couch_ini /etc/couchdb/default.ini /etc/couchdb/local.ini /etc/couchdb/default.ini /etc/couchdb/local.ini -s couch -pidfile /var/run/couchdb/couchdb.pid -heart
couchdb 2959 0.0 0.0 3932 304 ? Ss 20:45 0:00 heart -pid 2951 -ht 11
ec2-user 2963 0.0 0.1 103424 828 pts/1 S+ 20:45 0:00 grep couch
Here is the output of the ".couch" databases I have ( shown for user ownership and permissions)
$ ls -lat /var/lib/couchdb
-rw-r--r-- 1 couchdb couchdb 23 Oct 11 20:45 couch.uri
drwxr-xr-x 3 couchdb couchdb 4096 Oct 11 19:35 .
-rw-r--r-- 1 couchdb couchdb 79 Oct 11 19:35 database2.couch
-rwxrwxrwx 1 couchdb couchdb 79 Oct 11 19:00 my_new_database.couch
-rw-r--r-- 1 couchdb couchdb 4182 Oct 4 21:52 albums.couch
-rw-r--r-- 1 couchdb couchdb 79 Oct 4 21:42 albums-backup.couch
-rw-r--r-- 1 couchdb couchdb 4185 Oct 4 21:30 _users.couch
drwxr-xr-x 18 root root 4096 Oct 4 20:58 ..
drwxr-xr-x 2 root root 4096 Oct 4 18:34 .delete
Here is my first attempt to DELETE
$ curl -X DELETE http://127.0.0.1:5984/my_new_database
{"error":"unauthorized","reason":"You are not a server admin."}
And my second attempt using an authenticated user.
$ curl -X DELETE http://brian:brian#127.0.0.1:5984/my_new_database
{"error":"error","reason":"eacces"}
The username/password of brian/brian was added to the [admin] section of /etc/couchdb/local.ini
Here is the output of my "_users" file. The "key" and "id" fields confuse me.
$ curl -X GET http://brian:brian#127.0.0.1:5984/_users/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"_design/_auth","key":"_design/_auth","value":{"rev":"1-c44fb12a2676d481d235523092e0cec4"}}
]}
Have you restarted your CouchDB after you added to user to local.ini? If so, has the password in the file been hashed or is it readable?
Generally your file permissions look OK, so I can't tell what exactly causes the error. For a quick fix you can simply delete the .couch file, though.
This question is really old, but since I got bitten by this today and this is where Google led me, I thought I'd share my solution for others that stumble here. In my case, my Couch lib directory (/usr/local/var/lib/couchdb for me) had a directory called .delete that was owned by root. Changing the owner to couchdb let me delete databases again.
I'm trying to run the command, chown -R apache:apache xyz
But I'm getting error, chown: apache:apache': invalid user
Then I tried for the user www-data, but with same results.
Then I tried to check who owns the apache process by running, ps -Af |grep httpd.
I get the following,
root 29577 1 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29754 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29756 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29757 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29758 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29759 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 29760 29577 0 18:00 ? 00:00:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
root 29785 29358 0 18:04 pts/0 00:00:00 grep httpd
So, where is the apache user?
Thanks.
Your apache runs as the user called "nobody" (Yes nobody is a username).
I have newer seen a linux where the apache user were called apache but you can configure the name in the apache config. Which linux version are you using?
look in the configuration for apache - httpd.conf. The following lines should give you the needed informations.
For the user do:
find / -name httpd.conf | xargs grep -i "^user"
and for the group do:
find / -name httpd.conf | xargs grep -i "^group"
-Martin
the user called "www-data" in apache2
Not all linux servers use apache and group apache. It looks like the server is running the process as nobody.
Are you root on the server? If so you can look in the /etc/groups file to see what groups are defined.
I've got the same problem when triyng to make the chroot with only some libraries. When I tried to su the same message was happened:
su: user xxxxxdoes not exist
Seems not all libraries was copied to the chroot subdirectory, so you can try to copy all if you've prepared the chroot dir
cp --parent -avR /usr/lib64 /CHROOT_DIR
cp --parent -avR /usr/lib /CHROOT_DIR
ln -s /CHROOT_DIR/usr/lib64 /CHROOT_DIR/lib64
ln -s /CHROOT_DIR/usr/lib64 /CHROOT_DIR/lib64
This ps aux | egrep '(apache|httpd)' OR apachectl -S can also help you see what the user is. For me it was www-data