About 1000 IoT devices are sending data to my server with TCP/INETD. Everything worked fine with Ubuntu 16.04. After Upgrading to 18.04 only 160 devices can be connected.
I already increased noproc, nofiles etc - nothing changes.
I made a very simple script which only accepts the connection, waits 10 seconds and quits. No changes. Not more then 160 devices.
Is there a limit for TCP-Connections?
From 16.04 to 18.04 has changed default of DefaultTasksMax:
16.04: 18446744073709551615
18.04: 105
Edit /etc/systemd/system.conf DefaultTasksMax=infinity or f.e. DefaultTasksMax=4000.
Related
Since a day or so I can not access the databases on two of my servers any longer
I use
mysql -h host.sld.TLD -P 3306 -user user
which I have configured to allow my user from my host without password
but get the above error.
However, when I use
telnet host.sld.TLD 3306
I get
5.5.5-10.8.5-MariaDB-1:10.8.5+maria~ubu2004(si4cyW'Y��-n;{ypDA\)VU)mysql_native_passwordC
I am using homebrew's mariadb (currently 10.9.3) on my machine, which I can reach from the outside. One each of the 'failed' remotes is on ubuntu with 10.8 and one on a Mac also with 10.8, and outgoing works from both. OpenSSL is version 1.1.1s on both Macs
I have installed a number of different mariadb versions all have the same issues, as do their perl libraries. mysql itself works.
What am I doing wrong here?
This issue has been fixed in MariaDB 10.9.4 which was released yesterday. Brew still offers 10.9.3, usually it takes a couple of days until latest 10.9 release will be available via brew.
The issue doesn't affect the server itself, but Connector/C and command line tools which link against Connector/C.
See also: MariaDB connector in Python cannot connect to remote server
I have a DHCP Server working on PFSense 2.4.4. While it works perfectly with RHEL 7/CentOS 7 machines, it doesn't work on RHEL6/CentOS 6 (both with fixed IP or dynamic range).
This is what DHCP Server Logs show (IP and MAC are obfuscated):
DHCPREQUEST for xxx.xx.255.15 from aa:bb:cc:dd:ee:ff via bge0
DHCPACK on xxx.xx.255.15 to aa:bb:cc:dd:ee:ff via bge0
send_packet: Host is down
dhcp.c:3976: Failed to send 318 byte long packet over fallback interface.
Here is what service network restart shows in CentOS 6:
Restarting network service
And here is what /var/log/messages shows (xxx.xxx.255.3 is the Pfsense DHCP Server address; xxx.xxx.255.1 is the default route; xxx.xxx.255.15 is the supposed address that should be bound to the machine):
Messages file
Lastly, here is my PFSense server info if it helps:
BIOS Vendor: Dell Inc.
Version: 2.6.0
Release Date: Tue Oct 31 2017
Version 2.4.4-RELEASE (amd64)
built on Thu Sep 20 09:03:12 EDT 2018
FreeBSD 11.2-RELEASE-p3
CPU Type Intel(R) Xeon(R) CPU E5-2620 v3 # 2.40GHz
24 CPUs: 2 package(s) x 6 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (inactive)
I've tried rebooting those Centos 6 machines, rebooting PFSense, and I made sure the machines and PFSense packages are all updated. Nothing works.
Any help is appreciated.
After struggling with this I found this in DHCP Server option in PfSense:
Additional BOOTP/DHCP Options
I configured it like this:
Additional config
Turns out DHCP wasn't providing the Subnet Mask to CentOS 6 instances and with this option enabled, the mask is appended to the lease file.
I installed Ubuntu 18.04 on Hyper-V Win Server 2016.
And network performance of the Ubuntu is bad: I'm hosting few sites (Apache + PHP) and sometime response time is > 10 seconds. Sometimes it is fast.
As I troubleshooted, I see this netstat results:
# netstat -s | egrep -i 'loss|retran'
3447700 segments retransmitted
226 times recovered from packet loss due to fast retransmit
Detected reordering 6 times using reno fast retransmit
TCPLostRetransmit: 79831
45 timeouts after reno fast retransmit
6247 timeouts in loss state
2056435 fast retransmits
107095 retransmits in slow start
TCPLossProbes: 220607
TCPLossProbeRecovery: 3753
TCPSynRetrans: 90564
What can be cause of such high "segments retransmitted" number? And how to fix it?
Few notes:
- VMQ is disabled for Ubuntu VM
- The host system Network adapter is Intel I210
- I disabled IPv6 both on host and in VM
Here is WireShark showing, that it takes ~7 seconds to connect (just initial connection) to my site Propovednik.com:
Sep 20: So far, the issue seems to be caused by OVH / SoYouStart bad network:
This command shows 20-30% packets loss:
sudo ping us.soyoustart.com -c 10 -i 0.2 -p 00 -s 1200 -l 5
The problem could be anywhere along the network, including the workstation where you work from. I suggest you check the network as retransmissions and packetloss means that either something is malfunctioning or misconfigured. If this is on a wireless network, you could be out of range of your router.
I am pinging the website you noted from my computer and there is no packetloss.
Trying to get Dropbear to work with Ubuntu Server 16.04 to enable for remote disk decryption to.
I am following this tutorial
But failing at this step: sudo cp /etc/initramfs-tools/root/.ssh/id_rsa ~/id_rsa_dropbear
as the file: /etc/initramfs-tools/root/.ssh/id_rsa dose not exit on Ubuntu Server 16.04.
Any help would be great.
Thanks
alexis
Manage to figure it out in the end. I ended up writing a blog post about it here Unlocking Ubuntu Server 16 encrypted LUKS using Dropbear SSH. The post I wrote is very heavily based from the answer I found here SSH to decrypt encrypted LVM during headless server boot? and all did was change the version 16 specific parts.
cheers
alexis
I am trying to launch an instance in Openstack.
Instance : SecurityOnion.iso
Flavor : 14 GB RAM
Root disk : 20 GB
vCPUS: 5
Host RAM: 20 GB
Host OS: Centos7
When the xUBUNTU security Onion console shows up after I launch the instance on the dashboard, I am unable to work smoothly. The response time is very high, hence facing an issue with the speed. Any suggestions on how to speed it up? What could be the possible factors?