On centos
sudo lokkit -s http
opens up the service.
I have been reading the documentation and I was googling for a while, but I cannot figure out how to turn off the service (undo the result of the above). Surely the writers of lokkit must have thought that that would be needed, so it must be there somewhere. Thanks!
Related
I am trying to configure or setup the production environment of whatsapp business api as mentioned in the link https://developers.facebook.com/docs/whatsapp/installation/prod-single-instance
I have done everything mentioned in this my dockers are also running on port:9090 as can be seen in the image
still I can't access it. Whenever I try to call https://localhost:9090 the error with "This site can’t be reached" occurs. Whatsapp business api does not have good documentation or tutorials till now. So this site is the only last way for me.
I had a similar problem which could be your case, I saw the docker containers OK but nothing was working. After a day searching I saw where it happened, my problem was I installed mysql MANUALLY (not docker container) in the same instance where docker is running and in db.env I just used 127.0.0.1, this was passed literally to docker container, then looking at a the wait_on_mysql.sh script, the whastapp docker containers were waiting util the mysql ip has conectivity to actually do something and was printing "MySQL is not up yet - sleeping" each second, of course they wouldn't find any conectivity.
Since my instalation is for development, and I am already using such database to other stuff, my solution was to use the 172.17.0.1(docker gateway of the containers) IP instead, then add two sets of network iptables rules to the host to redirect from the docker containers IP to the IP binded by mysql when using such port (3306, the default in my case). After that everything works well. I think there are better solutions, but I didn't want to go far on it, you should evaluate you case if apply.
check the command:
docker-compose logs > debug_output.txt
That gives you insight about whats happening, hope it can helps someone.
I think your setup is already complete. You just need to start with the registration process and start sending messages. The containers are up and running but calling https://localhost:9090 won't send you any response as this is not any specified API endpoint expected to be used.
Since you're using prod single instance, the documentation can be found here which seems pretty straight forward. https://developers.facebook.com/docs/whatsapp/installation/prod-single-instance
You seem to have completed till the 7 steps. The next step can be to perform a health check to make sure it is healthy. The API endpoint for that would be https://localhost:9090/v1/health https://developers.facebook.com/docs/whatsapp/api/health
Has your db also been setup?
I cannot see it in the docker screenshot.
Also - you have to accept the certificate, as it does not have a public CA issues certificate.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 10 months ago.
Improve this question
I am new to CentOS 7 and I am configuring a static IP on CentOS 7, so I have edited the file /etc/sysconfig/network-scipts/ifcfg-eth0 as following:
TYPE=Ethernet
BOOTPROTO=none
Device=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
DNS1=8.8.8.8
USERCTL=no
But when I issue the command
systemctl restart network
I am getting the error
failed to start LSB :/Bring Up down Networking
ip route show gives me no output.
I have applied the solution that stops NetworkManager with the same existing error.
I am able to configure a dynamic DHCP and get a dynamic IP address but not static one.
What can be possible solutions?
Its because of interface issue
Solution worked for me was:
Check the interface available
cp ifcfg-eno16780032 ifcfg-ens192
vi ifcfg-ens192 and change NAME and Device field to ens192
systemctl disable NetworkManager
systemctl status NetworkManager -> inactive
systemctl stop network
systemctl start network
After that check ip a
get the details of IP and able to ping that IP.
You should change BOOTPROTO to static and move your DNS config to your /etc/resolv.conf file, for example:
TYPE=Ethernet
BOOTPROTO=static
PHYSDEV=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
USERCTL=no
When facing this issue that derailed proper autossh functionality on my roaming laptop, I decided to rip apart whatever of my MageiaOS code to understand the root cause. I did not have NetworkManager, so knew for sure it was not the obstacle.
The found issue could be described as kind of eventual live-lock between SysV and systemd ways of managing network service. Potentially, many conditions could trigger it (NetworkManager is one of the examples), in my case it was misconfigured vboxnet ifaces from VMWare.
There're two critical blockers in each part of SysV/systemd balance that might start triggering each other in the loop. On SysV side, init.d/network script eventually calls "ifup $device boot", which in response of 'boot' parameter starts ifplugd daemon for pluggable ifaces. The problem with this daemon that despite of '-I' switch (used to ignore errors) it still fails with exit code 4 upon detecting itself in memory. The only proper way to shutdown this daemon from network script is issuing "ifdown $device boot" command, which is supposed to get executed upon stopping network service by 'service' or 'systemctl' commands.
The interesting part of this question: why ifplugd is already in memory before the network service starts? Well, in my case WiFi iface was fired before misconfigured vbox iface but the latter caused entire initscript to fail. So, network was started on boot but service status was recorded as failing. But what prevents us just stopping network service and consequently killing ifplugd from ifdown/boot command? The answer is: systemd in its ingenious ways of handling ExecStop directive in unit file (which is auto-generated on the fly for network service). Basically, "systemctl stop" command just ignores ExecStop directive if it believes that the service is not started. Well, of course it is not because... if previously failed stumbling on unexpected ifplugd instance! So, no way to stop the service, hence no way to get rid of ifplugd, hence no way of (re)starting the service and so on.
Conclusion. There's no single recipe for this sort of trouble because the compatibility balance between network script and systemd approach is very fragile, so many unexpected factors can start interfering. To troubleshoot this scenario, several statuses might be useful:
network service: systemctl status network
ifplugd service: ps ax|grep ifplugd
network link status: ifconfig / iwconfig
autogenerated unit: cat /var/run/systemd/generator.late/network.service
other places running ifup independently: grep -rs ifup /etc
and of course, "bash -x" and debugging "echo Bump" instruction. :-)
Long-term solution is fixing ifplugd to honour '-I' switch in this scenario. Mid-term solution is fixing /etc/sysconfig/network-scripts/ifup-eth for ignoring ifplugd return code. Short-term solution seems to be the most tricky, which is just removing all possible config factors triggering this live-lock. But this is the only one tolerating system autoupdates...
Execute tee /etc/modprobe.d/*blacklist*.conf <- "blacklist ideapad_laptop"
Then reboot. This should unblock your Wi-Fi.
I came here looking for a answer to my case so I'll share, maybe it will help someone else. I'd like to thank cPanel staff for pointing this out to me
As for the reported issues, we have seen the CloudLInux servers running a kernel version lower than "3.10.0-862" and update to Cloudlinux 7.7, they will get an update to the 'iproute' package.
The 'iproute' package needs to wither a newer kernel or to be excluded from updating onto the server initially.
This information has been reported. You can find some more information about it here:
https://www.cloudlinux.com/cloudlinux-os-blog/entry/cloudlinux-os-7-7-released
In my case
journalctl -xe
Shows there was a duplicate interface configuration eth0 & eno1 using the same UUID:
Nov 06 09:35:41 4200-150-137 /etc/sysconfig/network-scripts/ifup-eth[27549]: Device eno1 does not seem to be present, del
Nov 06 09:35:41 4200-150-137 network[27401]: [FAILED]
Nov 06 09:35:41 4200-150-137 network[27401]: Bringing up interface eth0: [ OK ]
removing the unused interface ifcfg file solved the problem for me.
After several trials including restarting of network manager, commenting out the UUID on the interface concerned (mine being ifcfg-eth0), it finally boiled down to a missing file which apparently needs to be included despite the fact that its values can be included directly in the interface file.
vi /etc/sysconfig/network
then add your right values and save:
NETWORKING=yes
HOSTNAME=xxx.xxx.xxx
GATEWAY=x.x.x.x
I hope this helps someone. It is tested on CentOS 7 as a guest VM on Hyper V on Windows 10.
I have VPS with OVH and have been struggling with similar issue.
Just wanna share my solution as it can help some people.
It used to delay boot by 5 minutes, dhclient was checking ipv6 on ifup call.
Set this to no
DHCPV6C=no
inside /etc/sysconfig/network-scripts/ifcfg-eth0
I know this is an old discussion but i had this problem on my bare metal server from ovh after disable NetworkManager service by installing CPanel
This issue solved by adding bellow parameters' in ifcfg-eno1 (or in your case any active interface)
LINKDELAY=31
NM_CONTROLLED=no
ONBOOT=yes
DHCPV6C=no
Also note that you have activated the network service
I'm trying to install Grafana on a server, and installation goes through properly. However, when I try to start the service (using sudo service grafana start) it fails with the cryptic message:
2016/02/11 18:45:38 [web.go:93 StartServer()] [E] Fail to start server: open : no such file or directory
I have been unable to find an answer to this.
I assume that I'm simply missing an apt-get package or something really simple, but there's no more information than this.
Anyone have an idea?
Thanks for your time.
EDIT:
While unable to solve the actual problem, I realized that though I configured the server to run over HTTPS, the actual SSL is handled through the proxy by my host, and the server should run internally on HTTP. When changing this, the server started properly. It's not a solution to this specific problem, but as it may point others with this problem in the right direction;
the problem had to do with running over HTTPS.
Good luck!
when configuring Grafana to use HTTPs you need to specify cert & key paths, looks likely that Grafana could not find one of them.
I am installing the MapR and I stucked at starting warden after start zookeeper on a single node.
# service mapr-warden start
Error: warden can not be started. See /opt/mapr/logs/warden.log for details
On this file there is no detail. Does anybody have a hint? Thanks =)
If you aren't getting anything in warden.log, then it's likely that the warden JVM is never even being started by the mapr-warden init script.
In some MapR versions, the mapr-warden init script will log some details into /opt/mapr/logs/wardeninit.log. You can try checking there.
However, I will also caution that currently the logging done by the init script is sparse and not necessarily user friendly to read. If you can't discern the cause from the contents of the wardeninit.log you can post them here and maybe I can help.
Another thing you can do is edit /etc/init.d/mapr-warden and add "set -x" towards the top of the file, right before the "BASEMAPR=" line, then try starting warden again and you'll get a bunch of shell debugging output on your screen. If you copy and paste that output here that should be enough to tell the root cause of the problem.
One more thing to mention, you may be better off using the http://answers.mapr.com forum as that is MapR specific and I think there may be more users there that could help.
Was configure.sh (/opt/mapr/server/configure.sh -C nodeA -Z nodeA)run on the node? Did zookeeper come up successfully?
service mapr-zookeeper status
Even when using MapR in a single node configure.sh is still required. In fact, without configure.sh warden, zookeeper, cldb and other MapR components will lack their configuration and in many cases will fail to start.
You must run configure.sh after installing the software packages (deb or rpm).
CentOS 5.5
I have a web application running on a server and it needs access to another CentOS server's file system running in the same network (via private IP). After doing a bunch of googling it looks like mounting the drive via NFS is a good way to go, but I'm not finding any good step by step instructions on how to go about it. I've read the man docs on the mount command and read some docs on the CentOS wiki as well but I feel like I'm missing something. Here is what I'm trying
mount -t nfs my.ip.address:/somePath /somePath/mount
I keep getting a 'no route to host' error but I can ping the server just fine. I'm guessing that I am possibly missing a port I need to open or something, but again, can't find information that makes sense to a non-sysadmin like myself.
Thanks for any help.
I ran across this, followed it step by step, and now I'm up and running!
http://www.cyberciti.biz/faq/centos-fedora-rhel-nfs-v4-configuration/