[03:12] <mahdi_ja> i configure a ftp server and when i want connect to it i get this error : packet_write_wait: Connection to 127.0.0.1 port 22: Broken pipe
[03:12] <mahdi_ja> Connection closed
[03:16] <sarnold> mahdi_ja: port 22 is ssh
[03:17] <sarnold> did you configure sftp instead?
[03:17] <sarnold> (sftp is far better than ftp for most users)
[03:23] <mahdi_ja> sarnold, yes i configure sftp
[03:23] <sarnold> mahdi_ja: can you ssh to localhost?
[03:23] <mahdi_ja> yes i do this for test
[03:24] <mahdi_ja> sarnold, yes i do this for test
[03:24] <sarnold> mahdi_ja: so ssh works but sftp doesn't?
[03:26] <mahdi_ja> sarnold, whit ssh i get this error :Permission denied, please try again.
[03:27] <sarnold> mahdi_ja: I think solving that will go a long way
[03:27] <mahdi_ja> sarnold, and how ?
[03:28] <sarnold> mahdi_ja: check the sshd logs, auth logs, see what errors it's reporting
[03:32] <mahdi_ja> sarnold, thank you
[03:32] <sarnold> mahdi_ja: time for me to run, have fun, good luck, and paste errors to a pastebin if you need more, hopefully someone will be around :)
[10:39] <emOne> Are there some default lists of ports that should be closed by default?
[10:40] <emOne> are there any ports which are already closed on ubuntu server ?
[10:41] <lotuspsychje> emOne: security is a wide area to deal with
[10:41] <lotuspsychje> emOne: try to nmap yourself externally, to see whats open and what not
[10:42] <lotuspsychje> emOne: the attacker is always looking for 24/7 servers with interesting services that are exploitable
[10:44] <emOne> I believe none of my ports are firewalled
[10:44] <lotuspsychje> emOne: its a combo of interesting services they are after, updated or not is important
[10:44] <lotuspsychje> emOne: try nmap -PN -sV ip for services
[10:45] <emOne> lotuspsychje: I received an email saying I should do something about my port 111 which is used by portmapper
[10:47] <lotuspsychje> emOne: running NFS?
[10:48] <emOne> lotuspsychje: I am not sure. I locked myself out while activating the firewall
[10:49] <emOne> trying to get back online
[11:43] <weedmic> Before I write a programme to do the following, is there already such a tool?  runs every x mins, check items v triggers, if trigger is met, send warning email, if triggers not met, apend to report.  captures snapshot of cpus usage, memory usage, storage remaining.  Sends report once each day, sends triggers immediately.
[11:50] <lordievader> weedmic: This sounds like Zabbix
[11:57] <weedmic> will check - i normally use htop and have a big monitor with lots open all the time, but, this is for someone in the backoffice to glance at once a day.
[12:31] <vlt> weedmic: Or Nagios/Icinga.
[12:53] <lordievader> weedmic: Zabbix will nag at you when things hit the fan 😋
[13:48] <weedmic> when htop reports "load average = 18.6" and I have 40 cpus, the number is cpu equivalents?  t/f?
[13:50] <nacc> weedmic: load average is about (in some sense) runnable processes, it's not normalized to how many cpus you have
[14:01] <weedmic> so, 18.6 means about 18 processies are running at the same time on average?
[14:02] <weedmic> if so, how does one know when the number is high enough to be a concern/worry?
[14:17] <lordievader> It is not necesarily running. It means that 18.6 cores are busy a 100% of the time.
[14:18] <lordievader> What I typically do is normalize the load by dividing it between the number of cores/cpus available. That way if it reaches a 100% I know the machine is fully utilized. Above it the machine is over utilized, etc.
[14:24] <weedmic> ok, so it is like I thought, but you are saying cores not cpus.  I have a lot more cores than cpus, so 18.6 must be unimportant.
[14:24] <weedmic> i meant threads not cores nor cpus
[15:16] <nacc> weedmic: every hardware thread is a logical CPU in Linux; load isn't really core based -- it's logical CPU based
[15:17] <weedmic> Q
[15:44] <weedmic> to calculate average cpu load, i can do "inxi -x -C", add all the cpu (col 3) and divide by 5 (It only does top 5) - correct?
[15:48] <weedmic> nvm - the real thing i wanted was "cat /proc/loadavg”"
[16:43] <teward> ahasenack: can i coopt you to do some nginx testing for me?
[16:43] <teward> very basic tests but :P
[16:43] <ahasenack> teward: probably :)
[16:44] <teward> ahasenack: can you install nginx from bionic updates, remove the IPv6 listen line, and then restart NGINX, and see if it still listens on IPv6?
[16:44] <ahasenack> that would be odd if it did
[16:44] <teward> from what I can tell a straight `listen 80;` will still listen on both v4 and v6 in most modern setups
[16:44] <ahasenack> and the host, ipv6 enabled? For this test
[16:44] <teward> since listen 80 without 0.0.0.0 is a "bind all"
[16:44] <teward> yeah
[16:44] <teward> and then if you want to test with v6 disabled feel free
[16:44] <ahasenack> let me get a vm then
[16:45] <teward> ack
[16:45] <teward> to my knowledge based on the documentation, listen :80 is equivalent to "LIsten on port 80 on all available interfaces and IP addresses"
[16:45] <teward> and listens on 0.0.0.0:80 and [::]:80
[16:47] <ahasenack> upstream said in the upstream bug that by default nginx doesn't listen on ipv6, though
[16:47] <ahasenack> but we shall know in a few
[16:48] <ahasenack> teward: hm, looks like it stops listening on ipv6: https://pastebin.ubuntu.com/p/McKNnMTBSS/
[16:48] <teward> hmm
[16:49] <teward> ahasenack: AIUI though disabled IPv6 is nonstandard
[16:49] <teward> and not the 'norm'
[16:49] <teward> therefore this is an edge case that we can't easily adapt for...
[16:49] <ahasenack> I tend to agree
[16:49] <ahasenack> sshd ships with
[16:50] <teward> i could have SWORN we had another bug like this
[16:50] <ahasenack> #ListenAddress 0.0.0.0
[16:50] <ahasenack> #ListenAddress ::
[16:50] <ahasenack> commented like that
[16:50]  * teward digs into it
[16:50] <ahasenack> and it doesn't fail to start if ipv6 isn't there
[16:50] <ahasenack> but I think it would fail if the ipv6 line was uncommented
[16:50] <ahasenack> and ipv6 was not supported
[16:51] <teward> fairly sure https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592 is a dupe of this
[16:51] <ahasenack> agreed it is
[16:52] <teward> duped it
[16:52] <teward> we could introduce this in Eoan first
[16:52] <teward> see if there's any whining/moaning
[16:52] <teward> but it's not SRU-able on its own
[16:53] <teward> rbasak: ^ in case you want to check my brain on this
[16:53] <teward> but i'm fairly sure a 'default config' change SRU is not going to be enough to be SRU worthy on its own
[16:54] <teward> nor would such an SRU actually *get* to the end users side of things because of how config files're handled
[16:56] <rbasak> Sorry, I'm just finishing one thing and then I need to run.
[16:56] <rbasak> I'll try to remember to look later
[16:57] <ahasenack> teward: I tend to agree. The main argument being, I think, that if you changed your system to completely disable ipv6, at the OS level, then you should also take care of individual configuration changes that are needed per service
[16:58] <teward> rbasak: no problem, it's not SRUable in my opinion and because of how dpkg handles config files files would not get overwritten by default.
[16:58] <teward> just wanting to check my brain here :)
[16:58] <ahasenack> because this could be surprising in the other way around too: you want ipv6 enabled, you have configured a listen directive for it, then for reasons outside your control suddenly ipv6 is disabled and your site is not reachable via that protocol anymore
[16:58] <teward> ahasenack: that's also my opinion.  we could comment out the v6 line for Eoan+ but not get that backports.
[16:58] <ahasenack> nginx not starting up is a valid failure mode
[16:58] <teward> yep
[16:58] <teward> and we even have that in the config if port 80 is already bound to
[16:58] <teward> at least, in later
[16:58] <teward> later NGINX versions in Ubuntu*
[19:46] <axisys> tcpdump on port 443 shows packets coming, openssl s_client -connect remote:443 gets certificate , but netstat -tunlp | grep 443 shows only port 8443 .. what is tied to port 443 ?
[19:46] <axisys> https://remote takes me to the site
[19:47] <tds> axisys: just to check, you're running that netstat command on "remote"?
[19:48] <tds> either way, I'd check for iptables rules, port 443 may be redirected to a different local port
[19:48] <axisys> yes running on remote :-)
[19:49] <axisys> tds: ah.. that was it
[19:49] <axisys> tds: -A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8443
[19:49] <axisys> tds: thank you