I have a mounting problem with a Solaris 2.7 and linux SuSE SLES 12 machine. The Solaris machine should mount a NFS from a SLES 12 machine. I have two SLES 12 SP4 machine running. The error I got from the machine that is not working is: "NFS getacl failed for server xxxxx: error 9 (RPC: Programm/Version mismatch)". On the other machine the mount works fine.
I search and tried a few things (including NFS Versions, export and mount options) but the main different between the machine that is working and the machine that is not working is the output of the rpcinfo -p.
The machine that is working show the entries:
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
And on the machine that is not working:
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
all entries with 100227 nfs_acl are missing.
The command lsmod show that nfs_acl is in the kernel included. Which settings/switch/option i'm missing to activate the missing acl_nfs. I bet this would solved the problem.
I got the solution. On the machine I got the error I needed to try out a new software package and therefore a vendor change to openSUSE of a few packages are made and the kernel was changed too! Both kernels 4.x and 5.3.x were installed parallel and 5.3.x was active. And this combination result in the problem. I checked for updates and realize that I stuck at this version. There are newer versions of 5.3 and 4.x available but I was not able to install them.
I fetched all packages from the openSUSE vendor and changed it back and deinstall the 5.3 kernel. After rebooting the 4.x kernel and upgrading it to 4.12.14 the nfs_acl are available and the solaris NFS works fine.
Related
i got the connection like this
sip flow
freeswitch server --(sip)-- > opensips ----(wss)---> sip client in chrome with jssip/webrtc
the rtp flow
freeswitch server ---- > rtpengine-------> sip client in chrome with jssip/webrtc
the sip client is registered in opensips, when sip calls is originated, opensips will shift the sip call to wss protocol while the rtpengine will transfer the rtp stream in an encrypted way.
everything works fine unless the part between rtpengine to jssip client. the call will hangup in 30 sec due to NO MEDIA by freeswitch.
i checked the logs in rtpengine, and found these warnings and error,
ERR [crypto] Failed to init DTLS connection: key values mismatch
WARNING [core] ICE restart detected, but reset not allowed at this point
ERR [rtcp] SRTCP output wanted, but no crypto suite was negotiated
Here is my configure part for rtpengine offer in opensips.cfg
branch_route[1] {
# couples of lines omitted
$var(rtpengine_flags) = "RTP/SAVPF SDES-no rtcp-mux-offer replace-session-connection replace-origin ICE=force address-family=IP4 out-iface=pub in-iface=pub";
rtpengine_offer("$var(rtpengine_flags)");
}
Here are the SDP negotiation part
rtpengine-> jssip client in INVITE
v=0
o=FreeSWITCH 1668770237 1668770238 IN IP4 8.210.107.107
s=FreeSWITCH
c=IN IP4 8.210.107.107
t=0 0
a=msid-semantic: WMS 2ImUufOQPNDojzwQRNjtlprF4InCfAd7
m=audio 42782 RTP/SAVPF 8 0 101
a=ssrc:1803089321 cname:8pRtvw9aaDpk3M0K
a=ssrc:1803089321 msid:2ImUufOQPNDojzwQRNjtlprF4InCfAd7 a0
a=ssrc:1803089321 mslabel:2ImUufOQPNDojzwQRNjtlprF4InCfAd7
a=ssrc:1803089321 label:2ImUufOQPNDojzwQRNjtlprF4InCfAd7a0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=rtcp:42783
a=rtcp-mux
a=setup:actpass
a=fingerprint:sha-256 A4:C8:C6:97:DA:0A:FA:BC:B9:C1:97:D2:22:EF:70:6D:A1:78:B9:F9:00:60:AC:DF:69:E3:60:DB:F7:EA:2C:F5
a=ptime:20
a=ice-ufrag:ODhSSSee
a=ice-pwd:sK872thzGVIdizUSWzfuVzEOWe
a=candidate:zGAW3IRHAMII4q3e 1 UDP 2130706431 8.210.107.107 42782 typ host
a=candidate:zGAW3IRHAMII4q3e 2 UDP 2130706430 8.210.107.107 42783 typ host
jssip client --> rtpengine in reply 200 OK
v=0
o=- 5243747727296622141 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS O9XWhjITMoc3TM2D2J9KMKWKOC7Bd0xR9DZf
m=audio 64247 RTP/SAVPF 8 0 101
c=IN IP4 10.11.0.34
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:589451690 1 udp 2122260223 10.11.0.34 64247 typ host generation 0 network-id 1 network-cost 50
a=candidate:3667169833 1 udp 2122194687 169.254.43.39 64248 typ host generation 0 network-id 2
a=candidate:2999745851 1 udp 2122129151 192.168.56.1 64249 typ host generation 0 network-id 3
a=candidate:6184858 1 udp 2122063615 169.254.223.104 64250 typ host generation 0 network-id 4
a=candidate:508951713 1 udp 2121998079 192.168.3.30 64251 typ host generation 0 network-id 5 network-cost 10
a=candidate:1839312218 1 tcp 1518280447 10.11.0.34 9 typ host tcptype active generation 0 network-id 1 network-cost 50
a=candidate:2484563673 1 tcp 1518214911 169.254.43.39 9 typ host tcptype active generation 0 network-id 2
a=candidate:4233069003 1 tcp 1518149375 192.168.56.1 9 typ host tcptype active generation 0 network-id 3
a=candidate:1323148138 1 tcp 1518083839 169.254.223.104 9 typ host tcptype active generation 0 network-id 4
a=candidate:1356202065 1 tcp 1518018303 192.168.3.30 9 typ host tcptype active generation 0 network-id 5 network-cost 10
a=ice-ufrag:xbP9
a=ice-pwd:5zKlMQDpo8aqCnJliT5bt6rH
a=ice-options:trickle
a=fingerprint:sha-256 12:FD:0A:B5:05:0B:0D:B8:62:7E:59:65:45:F9:5A:07:10:63:7C:0C:05:96:35:C9:27:D7:D7:7B:DE:C5:70:8A
a=setup:active
a=mid:0
a=sendrecv
a=rtcp-mux
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:2078142037 cname:ARU0gPhz4hvVPHMO
a=ssrc:2078142037 msid:O9XWhjITMoc3TM2D2J9KMKWKOC7Bd0xR9DZf f4a6248a-f3ca-4e23-a656-36b5d039ee3e
I tried to search any related issue or question and found issue 1524
However, it is no answer and solution for it yet.
I also read the source code of rtpengine, and realise it was from openssl, but i don't quite fimiliar with that. Hope anyone can help.
After a lot of ways to try, i just figured it out by myself.
before i tell the cause, i need to brief the process of dtls process of rtpengine.
when RtpEngine starts, it creates a certificate itself.
[1668851507.814949] INFO: [crypto] Generating new DTLS certificate
[1668851507.818173] INFO: [core] Startup complete, version undefined
the underlayer thing is invoking openssl api to create the certificate that interacts in dtls. this openssl api depends on the installed openssl lib in the os.
It performs as Servce end, and its gereated cert will be passed to the Client; My client is a webrtc sip client in Chrome, which has a latest version of openssl i guess.
It seems that client and server have different version for the encryption, which causes the error: key value mismatched
therefore, the root cause is old-version openssl lib.
i installed rtpengine in centos 7, which has a quite old version of openssl, like openssl 1.0.2k .( this is likely to be 2015 if i'm not wrong)
when i changed the os version to ubuntu 20, this issue was gone immediately.
And then I checked the base version of openssl that ubuntu 20 installed, it is openssl 3.0. I'm not sure whether this version is a must or not, but it works for this version.
So theoretically if you installed this verson of openssl in your OS, it could fix this issue.
but i didn't try that in centos 7 anyway.
Hope it can help the guys who encountered the similar issue like this.
Got strange stuff. Setup: VirtualBox + CentOs7 + python3.6 + scapy2.4.0
Got network with only 4-5 hosts active: gateway, CentOs in VirtualBos, PC on which VirtualBox running and something else.
Trying to do:
ans, unans = sr(IP(dst='10.10.10.1-100')/ICMP(), iface = 'enp0s3', retry=0, timeout=1)
Begin emission: ...
Received 1822 packets, got 99 answers, remaining 1 packets
ans
Results: TCP:0 UDP:0 ICMP:99 Other:0
unans
Unanswered: TCP:0 UDP:0 ICMP:1 Other:0
ans[x] - are legit ICMP Reply packets.
unans[0] - no ICMP reply from CentOs VM itself
So looks like everything is alive instead of 4-5 hosts which actually are alive
What could be the possible reason ?
You want to know the possible reason, but scapy is not giving you enough details. So use tcpdump:
$ sudo tcpdump -e -c 200 icmp
Send the probe packets while tcpdump is running, in order to view address and timing details. It is possible you are seeing lots of perfectly normal ICMPs, for example port unreachable, or network unreachable. Tcpdump will tell you exactly what went over the network interface.
I am setting up a Nexus OSS on an Azure VM.
I have set it up on a Ubuntu 16.04 LTS.
When I connect to the webapp via an SSH tunnel, I can access the Nexus repository manager. When I try to open it directly, I cannot get it to work.
As per the Azure docs and several Stackoverflow responses, I have updated the NSG and added port 8081 to be allowed but with no success. I also check the UFW (Ubuntu Firewall) and it is not even activated.
EDIT :
netstat -plant | grep 8081
tcp 0 0 127.0.0.1:33519 0.0.0.0:* LISTEN 18081/java
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 18081/java
tcp 0 0 127.0.0.1:8081 127.0.0.1:60242 TIME_WAIT -
tcp 0 0 127.0.0.1:8081 127.0.0.1:60366 TIME_WAIT -
tcp 0 0 127.0.0.1:8081 127.0.0.1:60244 TIME_WAIT -
EDIT2 :
admin#nexus-vm:~$ sudo iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
Does anyone have any idea what could be wrong?
Thanks in advance!
Regards
The problem was the firewall of my company. Tested it over 4G and it works.
I'm running a node/express app and it keeps dying randomly after a few hours.
The process is always still up, no logs or CPU/memory spikes or even much utilization but the process doesn't serve any requests anymore.
I suspect it's that the process has too many active UDP connections: lsof -i -a -p X | wc -l counted 9k+ network connections when I ssh'd into the docker-container running the node process, 98% UDP like this:
node 6 root 223u IPv4 614173 0t0 UDP *:63025
node 6 root 224u IPv4 324249 0t0 UDP *:34622
node 6 root 225u IPv4 415898 0t0 UDP *:44176
The #connections grows at a rate of exactly 10 new connections per minute.
The only UDP-related functionality in my app is https://github.com/sazze/winston-logstash-udp
Details:
Node v6.12.3 in Docker on AWS ec2 t2.medium
This behavior started happening after migrating from a debian:wheezy Docker base image to node:6.14.2-alpine.
Questions:
How can I further debug each UDP connection? E.g. target, duration, ... That would help find the underlying problem.
What is the limit for node's connection limit? I've read 4096.
This problem didn't occur under debian, what differences are there that might be related?
Hi all I have successfully installed Oracle 11g Express addition on a Linux VM (google cloud compute)
I have sqlplus working and I can query data.
The listener is also working.
But as there is no GUI with Linux servers I cannot try local host and external machines have the connection refused.
My Questions are:
1) Does Apex come pre-installed on Oracle XE it used to but not mentioned anywhere.
2) if the ip address of the server is 123.123.123 what url would I use to get to apex from a remote machine? I have tried
http://123.123.123:8080/apex/
http://123.123.123/apex/
https://123.123.123:8080/apex/
3) How can I tell if it is the server or Oracle refusing the connection?
Firewall
$ netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 10.128.0.3:50776 169.254.169.254:80 ESTABLISHED
tcp 0 0 10.128.0.3:43548 10.128.0.3:1521 ESTABLISHED
tcp 0 0 10.128.0.3:50722 169.254.169.254:80 CLOSE_WAIT
tcp 0 0 10.128.0.3:50814 169.254.169.254:80 ESTABLISHED
tcp 0 0 10.128.0.3:50774 169.254.169.254:80 ESTABLISHED
tcp 0 64 10.128.0.3:22 74.125.41.105:38312 ESTABLISHED
tcp6 0 0 :::40070 :::* LISTEN
tcp6 0 0 :::8080 :::* LISTEN
tcp6 0 0 :::1521 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:25 :::* LISTEN
tcp6 0 0 10.128.0.3:1521 10.128.0.3:43548 ESTABLISHED
Listener
$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 22-AUG-2017 02:59:51
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date 22-AUG-2017 02:00:17
Uptime 0 days 0 hr. 59 min. 33 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Default Service XE
Listener Parameter File /u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/centossmallblockpro/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=centossmallblockpro.c.sincere-destiny-176110.internal)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=centossmallblockpro.c.sincere-destiny-176110.internal)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "XE" has 1 instance(s).
Instance "XE", status READY, has 1 handler(s) for this service...
Service "XEXDB" has 1 instance(s).
Instance "XE", status READY, has 1 handler(s) for this service...
The command completed successfully
SQLPLUS working
sqlplus
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 22 03:03:51 2017
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Enter user-name: system
Enter password:
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
SQL> select * from dual;
D
-
X
.
Telnet XX.XXX.XXX.XX 8080
Telnet: Unable to connect to remote host: Connection timed out
1) Oracle XE (11g) comes with APEX version 3.2 I think. This is a very old APEX release. Follow the instructions how to drop this old version and get the latest from otn.oracle.com. Latest version should also work with 11g XE.
2) Tunnel
You can create a ssh-tunnel from your desktop machine to the end-point server where your services are running. Now you can access services on remote machine from your desktop environment aka. sqlplus, SQL Developer, Firefox, etc..
# Access Your Database Remotely Through an SSH Tunnel
# ssh -L [local port]:[database host]:[remote port] [username]#[remote host]
# console 1: 9998 is just an arbitrary port > 1024. Can be anything.
ssh -N -L 9998:10.128.0.3:1521 -i ~/.ssh/id_rsa user#35.184.136.98
# console 2:
sqlplus user/pwd#localhost:9998/XE
# firefox:
http://localhost:9998/apex
Great answers to 1 and 2 from Bjarte but the actual problem was not the Linux firewall but the Compute engine firewall.
I didn't know it even existed, when you select the check box to open Http it created a rule to TCP:80 but I needed TCP:8080.
Here is the article that solved it for me cant open port on google compute engine ...