I have a server with Apache Directory Server installed. I can connect using the Apache directory studio over 10389. Now I would like to connect on 389 instead of 10389. I go into (as sudo) /var/lib/apacheds-2.0.0_M23/default/conf/ou\=config/ads-directoryserviceid\=default/ou\=servers/ads-serverid\=ldapserver/ou\=transports/ads-transportid\=ldap.ldif and I set ads-systemPort to
ads-systemPort: 389
However, now when I run I see...
java.io.IOException: Error while binding on /0.0.0.0:389
original message : Permission denied
Changing it back to 10389 works great. I am confused because I am using sudo, which should avoid permission issues. What am I doing wrong?
If you start the apache directory server as a service (or like sudo service apacheds... start), it will run as system user apacheds:apacheds and will have permission to listen on any well known port like 389. As a normal user, you usually don't have that permission.
Change ads-transportAddress to your IP address instead of default value in file ads-transportid\=ldap.ldif.
Related
I've setup a weblogic cluster with 2 managed servers.In order to configure node manager on both nodes i've followed the related article :
http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/01-12-001-ConfiguringandUsingNodeManager/Configuring_and_Using_NM.html
with the following configuration :
Machine-0 :
DomainsFile=/u01/app/oracle/config/domains/base_domain/Machine-
0/nodemanager.domains
LogLimit=0
PropertiesVersion=12.1.3
AuthenticationEnabled=true
NodeManagerHome=/u01/app/oracle/config/domains/base_domain/Machine-0
JavaHome=/opt/jdk1.8.0_131
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
ListenAddress=localhost
NativeVersionEnabled=true
ListenPort=5558
LogToStderr=true
SecureListener=false
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFile=/u01/app/oracle/config/domains/base_domain/Machine-
0/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50
Machine-1 (the second managed server) has the same configuration with the exceptions of ports (5557) and name.
Although node manager is successfully started on both machines (startNodeManager.sh on machine-0 and machine-1) from admin console on Machine-0 the following error occurs and node manager doesnt start :
weblogic.nodemanager.NMConnectException
nodemanager.log of Machine-0 has no indications of errors or any helpful stuff.
Any help would be appreciated.
thanks in advance
These are the things that I usually check when I am setting up a new WebLogic domain:
It is possible that the Listen Address of Machine-1 is not correct. Check the Listen Address of the machine from the WebLogic Domain Configuration. It should match the host's machine name. Using localhost might not work because the Admin Server is trying to connect to the Machine-1, which can be on the other server.
Make sure to check if the port is reachable from the Admin Server's machine.
Check that the Node Manager configuration uses Plain instead of SSL connection, as stated in your nodemanager.properties file. Under Environments > Machines, click the machine and go to Configuration Tab, Node Manager. Check if the Type is Plain and not SSL. Changing this will require a restart of the Admin Server.
Please verify the items below before you start nodemanager.
Check if the nodemanager.domains has your domain name listed.
Try to see if the ports are listening using the commands below.
netstat -an|grep 5557
netstat -an|grep 5558
Also, check if the nodemanager is reachable in weblogic console.
I'm trying to use Ambari.
First, because I cannot use the root permission of lab's server, I tried to start Ambari agent manually.
This is my conf of agent:
The server port is 8082, but I got this error in agent log:
server at http://172.19.104.24:8082 is not reachable.
Before that, I closed the SELinux of server, and added rules in server's iptables. So I can't figure it out.
Have you turned the iptables off? Did you edit the network configuration file (etc/sysconfig/network)? Also try running setenforce 0.
While starting my JBoss in domain mode (first instance), I am getting following WARN as part of server.log in the console....
I am curious to know what caused the issue...... does it needs to be rectified..... what are the implication if didn't go for any fix for this warning......
[Server:server-two] 13:55:55,198 WARN [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012210: Unable to use InetAddress.getLocalHost() to resolve address.
Host entry is missing. Make entry in hosts file...
If your system is windows, Start->Run->Drivers
->and make the host entry in etc/hosts (need admin rights to edit hosts file)
If your system is UNIX based,
->open the file $sudo vim /etc/hosts and make the host entry.
In the present scenario host entry is for local system, to get the local system ip in UNIX run $ifconfig and in Windows run >ipconfig in command prompt.
I am trying to use knife from my laptop to connect to a newly configured Chef server hosted on AWS. I know what is listed below is the right direction for me but I'm not sure how to go about this exactly.
If you are not able to connect to the server using the hostname ip-xx-x-x-xx.ec2.internal
you will have to update the certificate on the server to use the correct hostname.
I had this same problem. The problem is that EC2 instances place their private ip into their hostname file. Which causes chef to self assign certs to the internal ip. When you do knife ssl check you'll probably get an error message that looks like this:
ERROR: The SSL cert is signed by a trusted authority but is not valid for the given hostname
ERROR: You are attempting to connect to: 'ec2-x-x-x-x.us-west-2.compute.amazonaws.com'
ERROR: The server's certificate belongs to 'ip-y-y-y-y.us-west-2.compute.internal'
connecting to the public IP is correct however you'll continue to get this error if you don't configure your chef server to use your public dns when signing the cert.
EDIT: Chef's documentation used to have steps to correct this issue, but since the time I initially answered this question they have removed those steps from their tutorial. The following steps worked for me with Chef 12, Ubuntu 16 on an ec2 instance.
ssh onto your chef server
open your hostname file with the following command sudo vim /etc/hostname
remove the line containing you internal ip and replace it with your public ip and save the file.
reboot the server with sudo reboot
run sudo chef-server-ctl reconfigure (this signs a new certificate, among other things)
Go back to your workstation and use knife ssl fetch followed by knife ssl check and you should be good to go.
What you could ALSO do, is just complete steps 1 - 4 before you even install chef onto the server.
Update public IP on Chef Server
run chef-server-ctl reconfigure on Server (No reboot needed)
Update the knife.rb on Workstation with new IP address
run 'knife ssl fetch' on the Chef Workstation
This should resolve the issue, to confirm run 'knife client list'
You can't connect to an internal IP (or DNS that points to an internal IP) from outside AWS. Those are nonroutable IP addresses.
Instead, connect to the public IP of the instance, if you have one.
Have a VPS and access to WHM as cpanel.But how can i access the php.ini and also connect using SSH.With SSH getting error
Failed to connect to server:
Network error: Connection refused.
If there is a proxy that is blocking it?
This question is probably better asked at serverfault. Having said that, by default in common Linux distributions (Ubuntu, for example), SSHD is not running by default.
Verify that you are running an SSH server, and if you are still having issues, this is better taken somewhere more relevant.