I am currently migrating the server part of a Client/Server application from OpenVMS to Linux (RHEL). the communication is done via RPC. I now saw that the portmapper 'spreads' the assigned ports over the whole range instead of assigning one after the other (as it does in with OpenVMS).
I assign the ports by the following code (GNU-C):
(void)pmap_unset(server_nr, KOMVERS) ;
transp = svctcp_create(RPC_ANYSOCK, 0, 0) ;
if (transp == NULL)
{
fprintf(stderr, "cannot create tcp service.\n") ;
exit(EXIT_FAILURE) ;
}
if (!svc_register(transp, server_nr, KOMVERS, komprog_1, IPPROTO_TCP))
{
fprintf(stderr, "unable to register (%ld, tcp).\n",server_nr) ;
exit(EXIT_FAILURE) ;
}
server_nr is the number of the server program (starting from 800000000) used by the client to access the server.
After starting several server processes, I get
... using rpcinfo
800000101 1 tcp 0.0.0.0.250.211 - unknown
800000102 1 tcp 0.0.0.0.250.211 - unknown
... using netstat
Proto Recv-Q Send-Q Local Address Foreign Adress State PID/Program
tcp 0 0 0.0.0.0:52414 0.0.0.0:* LISTEN 1604/Server01
tcp 0 0 0.0.0.0:25600 0.0.0.0:* LISTEN 1606/Server02
I would prefer that the port mapper always uses a defined port (my application is the only on the machine) for security reasons, but I could not find out how to do this.
Can anybody help me?
Related
I have created a queue manager using
these commands in a linux machine
crtmqm MQ1
strmqm MQ1
runmqsc MQ1
the queue manager is created successfully,
i wanted to know on which port is the queue manager MQ1 running, i tried all possible ways netstat -au and also ps -ef command. It looks like it is running on a different port. I am unable to find the correct port number where it is running, could anyone help?
By default a new IBM MQ queue manager will not have a listener running on any port.
There is one default LISTENER object on a new queue manager which looks like this:
$echo "dis listener(SYSTEM.DEFAULT.LISTENER.TCP)"|runmqsc MQ1
....
1 : dis listener(SYSTEM.DEFAULT.LISTENER.TCP)
AMQ8630: Display listener information details.
LISTENER(SYSTEM.DEFAULT.LISTENER.TCP) CONTROL(MANUAL)
TRPTYPE(TCP) PORT(0)
IPADDR( ) BACKLOG(0)
DESCR( ) ALTDATE(yyyy-mm-dd)
ALTTIME(hh.mm.ss)
If you were to start this LISTENER the PORT(0) means to start on the default port which is 1414.
Best practice is to not use SYSTEM objects and create a new object such as:
DEFINE LISTENER(LISTENER.1414.TCP) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)
The CONTROL(QMGR) tells the queue manager to start the listener when the queue manager is started and stop it when the queue manager is ended.
You can manually start and stop the above listener with the commands:
START LISTENER(LISTENER.1414.TCP)
STOP LISTENER(LISTENER.1414.TCP)
Use netstat as root with -p option
sudo netstat -nltp
[sudo] password for root:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1362/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1580/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1480/cupsd
The last column gives the PID and 'Program name'. If you are running the queue manager with your user, you don't need to sudo.
I have a:
Rasberry Pi 2
running
Raspbian Jessie Version:November 2015
I am using Undertow (a Java http server) to serve a website. This is the code that I use to build the server.
Undertow server = Undertow.builder()
.addHttpListener(8890, "localhost")
.setHandler(Handlers.pathTemplate()
.add("/", resource(new PathResourceManager(staticFilePath, 100))
.setDirectoryListingEnabled(false))
.build();
Problem: I am unable to see the webserver from another machine on the local network despite being able to ping and SSH into the PI.
What I have done (on the Pi2):
wget localhost:8890
returns the index.html correctly
netstat -lptn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 127.0.0.1:8890 :::* LISTEN 1743/java
Chrome on my development machine 192.168.1.8:8890 gives
ERR_CONNECTION_REFUSED
wget 192.168.1.8:8890
Connecting to 192.168.1.8:8890... failed: Connection refused.
nmap 192.168.1.8
Starting Nmap 6.40 ( http://nmap.org ) at 2015-12-05 14:05 CST
Nmap scan report for 192.168.1.8
Host is up (0.039s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
Nmap done: 1 IP address (1 host up) scanned in 1.83 seconds
It is my understanding that there is no firewall so I am baffled as to why I can't see the server from my development machine.
See:
tcp6 0 0 127.0.0.1:8890 :::* LISTEN 1743/java
Your web server listens only on localhost address (127.0.0.1). This way it couldn't be accessed from anywhere but localhost.
And your nmap scan shows the same: the only remotely accessible port is 22.
To access this service remotely you have to bind web server to any non-local address belonging to this raspberry pi (192.168.1.8) or to "any address" 0.0.0.0, as SSH service is bound.
How to do this is written in the manual of your web server. Probably, you have to start is with a "-d" param, i.e.
standalone.sh -b=0.0.0.0
standalone.sh -Djboss.bind.address=0.0.0.0
or something like this.
In listener setup code this looks like
"localhost" have to be replaced with some public name. This could be "0.0.0.0" or "192.168.1.8". We also can
cat "192.168.1.8 somename" >> /etc/hosts
and then use somename:
Undertow server = Undertow.builder() .addHttpListener(8890, "somename")
I have an application running on Windows machine. the application related alerts are to be e-mailed to administrator,for which an e-mail needs to be sent by Java program. The SMTP server is configured on a remote Linux machine in network.
The Java Mail program works fine and sends out an email, when run on the Linux machine. However if the same program is run on Windows it fails to connect to the SMTP server.
Note:
Ping to the Linux Machine (having SMTP server) is successful from Remote windows server.
Telnet < SMTP server hostname > 25 fails from remote machine as well from the machine where SMTP is running
Telnet localhost 25 is sucessful from SMTP server (Linux server).
The email by Java program is sucessfull, if run on SMTP server when hostname is specified as localhost.It fails if you give actual hostname.
/etc/hosts file on SMTP server lists 127.0.0.1 localhost.
How can i use the SMTP server to send an email from remote Windows machine?
I can paste the errors coming up on windows machine but the problem is not with the program; its the way the SMTP server is configured. I am new to SMTP so feel free to correct me if i am wrong.
The objective is to send a java e-mail from remote windows machine using the SMTP server on the Linux machine.
Adding the Output of netstat -ant|grep :25 as requested in the comment below:
[root#XXXXXXXXXXX]# netstat -ant | grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 ::1:25 :::* LISTEN
tcp 0 0 ::ffff:10.207.70.71:1521 ::ffff:10.207.70.71:25481 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25481 ::ffff:10.207.70.71:1521 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25202 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:25127 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:25289 ::ffff:10.207.70.71:3001 ESTABLISHED
tcp 0 0 ::1:51432 ::1:25580 ESTABLISHED
tcp 0 0 ::1:25580 ::1:51432 ESTABLISHED
tcp 0 0 ::ffff:10.207.70.71:25233 ::ffff:10.207.70.71:3001 TIME_WAIT
tcp 0 0 ::ffff:10.207.70.71:3001 ::ffff:10.207.70.71:25289 ESTABLISHED
[root#XXXXXXXXXXX]#
Postfix: Accepting SMTP connections on ALL IP interrfaces
Your SMTP server (postfix) accepts incoming SMTP connection only on loopback interface(s)
[IPv4=127.0.0.1 and IPv6=::1].
Make your postfix listen on all available IP interfaces -> in main.cf configuration file restore default setting inet_interfaces = all
http://www.postfix.org/postconf.5.html#inet_interfaces
Why "loopback only" configuration is used?
Limiting SMTP server to accept only local SMTP connections is pretty common default configuration on "workstations". It allows sending emails (e.g. system warnings/notifications) without accepting any incoming spam.
Proto Recv-Q Send-Q Local Address Foreign Address State PID
tcp 0 0 ip:11080 0.0:* LISTEN -
tcp 0 0 ip:5070 0.0:* LISTEN -
tcp 0 0 ip:5071 0.0:* LISTEN -
tcp 0 0 **127.0.0.1:5072** 0.0:* LISTEN -
tcp 0 0 ip:11443 0.0:* LISTEN -
tcp 0 0 **127.0.0.1:11444** 0.0:* LISTEN -
Not able to access port (11444 & 5072) externally.
Only working on Local Host not remotely.
We are using Ubuntu on Google Compute Engine.
Firewall rules Added
Just checking - have you also configured the firewall? By default, the ports may be blocked by the firewall. You can configure it to enable ports via either the Developer Console, or with the gcloud command line tool.
Some extra information about firewall's on Google Compute Engine can be found at:
https://cloud.google.com/compute/docs/networking?hl=en#firewalls
As the netstat output shows, your services listening on port 11444 and 5072 are bound to localhost (127.0.0.1) which means they only accept connections on the local loop interface. Change the binding IP address on your service configuration to 0.0.0.0.
I am a new user of RedHawkSDR and have written a python program under CentOS that controls a "SigGen" component. It works if there is no network connection except the loopback, but fails if I connect a wired network (listed as System ethO).
I do not specify any IP address in the python program, and the omniORB.cfg explicitly lists the loopback address as shown below, since there have been comments in other posts warning against using "localhost"
traceLevel=10
InitRef = NameService=corbaname::127.0.0.1:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::127.0.0.1:11169/omniEvents
Comparing the ominORB data that prints to the screen from the two cases:
Last identical step ==> "omniORB: AsyncInvoker: thread id=2 has started. Total threads=1
Next step:
for working (no network) ==> "omniORB: Adding root<0> (activating) to object table
for nonworking (network connected) ==> "omniORB: Removing root<0> (etherealizing) from object table
full message stream for network connected case==>
[aecom#crancentos1 Desktop]$ python pTrigger.py keyboard 5555 5050
omniORB: Version: 4.1.6
omniORB: Distribution date: Fri Jul 1 15:57:00 BST 2011 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: omniORBpy distribution date: Fri Jul 1 14:52:31 BST 2011 dgrisby
omniORB: Initialising incoming endpoints.
omniORB: Attempt to set socket to listen on IPv4 and IPv6.
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
/usr/local/redhawk/core/lib/python/ossie/utils/sb/domainless.py:863:
DeprecationWarning: Component class is deprecated. Use launch() method instead.
warnings.warn('Component class is deprecated. Use launch() method instead.', DeprecationWarning)
omniORB: Adding root<0> (activating) to object table.
omniORB: Creating ref to local: root<0>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: Creating Python ref to local: root<0>
target id : IDL:omg.org/CosNaming/NamingContextExt:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: Version: 4.1.6
omniORB: Distribution date: Fri Jul 1 15:57:00 BST 2011 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: omniORBpy distribution date: Fri Jul 1 14:52:31 BST 2011 dgrisby
omniORB: Initialising incoming endpoints.
omniORB: Attempt to set socket to listen on IPv4 and IPv6.
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: Removing root<0> (etherealising) from object table
Traceback (most recent call last):
File "pTrigger.py", line 118, in <module>
sigGen=sb.Component("SigGen")
File "/usr/local/redhawk/core/lib/python/ossie/utils/sb/domainless.py", line 872, in __new__
raise AssertionError, "Unable to launch component: '%s'" % e
AssertionError: Unable to launch component: 'resource 'SigGen_2' did not register with virtual environment'
Is there a system variable/token/thing that is "127.0.0.1" in the loopback case that switches to the network IP address when the system makes the network connection, which then confuses omniORB?
Any constructive guidance would be appreciated...
Best Regards,
Brad Meyer
ADDITIONAL DATA
// Firewall is off=============================
// Smoking gun ?===============================
omniORB: omniORBpy distribution date: Fri Jul 1 14:52:31 BST 2011 dgrisby
omniORB: Python thread state scavenger start.
omniORB: Initialising incoming endpoints.
omniORB: Instantiate endpoint 'giop:tcp:127.0.0.1:'
omniORB: Explicit bind to host 127.0.0.1.
omniORB: Bind to address 127.0.0.1 ephemeral port.
omniORB: Publish specification: 'addr'
omniORB: Try to publish 'addr' for endpoint giop:tcp:127.0.0.1:46877
omniORB: Publish endpoint 'giop:tcp:127.0.0.1:46877'
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: giopRendezvouser task execute for giop:tcp:127.0.0.1:46877
==>omniORB: SocketCollection idle. Sleeping.
omniORB: State root<0> (active) -> deactivating
// ifconfig shows loopback running ==================
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:302 errors:0 dropped:0 overruns:0 frame:0
TX packets:302 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26197 (25.5 KiB) TX bytes:26197 (25.5 KiB)
// ping 127.0.0.1 works ===========================================
// netstat -tulpn SHOWS OMIN CONNECTED TO SOME PORTS=========================================
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:42451 0.0.0.0:* LISTEN 2409/omniEvents
tcp 0 0 REDACTED FOR POST 0.0.0.0:* LISTEN 2617/dnsmasq
tcp 0 0 0.0.0.0:50517 0.0.0.0:* LISTEN 2067/rpc.statd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2254/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2098/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2346/master
tcp 0 0 127.0.0.1:42251 0.0.0.0:* LISTEN 2022/omniNames
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1902/rpcbind
tcp 0 0 :::39409 :::* LISTEN 2067/rpc.statd
tcp 0 0 :::22 :::* LISTEN 2254/sshd
tcp 0 0 ::1:631 :::* LISTEN 2098/cupsd
tcp 0 0 ::1:25 :::* LISTEN 2346/master
tcp 0 0 :::2809 :::* LISTEN 2022/omniNames
tcp 0 0 :::11169 :::* LISTEN 2409/omniEvents
tcp 0 0 :::111 :::* LISTEN 1902/rpcbind
When multiple network interfaces are available, omniORB arbitrarily chooses one of them for publishing object references (see part 5 in http://omniorb.sourceforge.net/omni41/omniNames.html). In your case, it seems to be grabbing eth0 when you are network-connected, which is not playing well with omniNames for whatever reason (could be a firewall setting).
To get around this, I recommend adding the following line to your /etc/omniORB.cfg file:
endPoint = giop:tcp:127.0.0.1:
This will force omniNames to always use the local loopback instead of eth0. Given your current omniORB.cfg settings, I am assuming using localhost is acceptable for your application. If this is not the case (i.e., you really need to use eth0 instead of localhost), we will need to find the root cause of why omniNames is having trouble with your eth0 interface.
Clarification (since I can't use line breaks in the comments section):
Try turning the log level up to 40 and see if anything useful shows up between these log lines:
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: Removing root<0> (etherealising) from object table
I'm having trouble reproducing your problem. In my working case, I get something like this:
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: giopRendezvouser task execute for giop:tcp:127.0.0.1:60625
omniORB: Adding root<0> (activating) to object table.
I'm curious as to see if the IP on the second line looks suspicious for you.
I worked on this for a week… but finally found the solution as DrewC pointed me in new directions to look.
In the etc/host file, I added a line “ 127.0.0.1 ‘ComputerName’” and the problem went away.
Brad