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:12 |
sarnold | mahdi_ja: port 22 is ssh | 03:16 |
sarnold | did you configure sftp instead? | 03:17 |
sarnold | (sftp is far better than ftp for most users) | 03:17 |
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:23 |
mahdi_ja | sarnold, yes i do this for test | 03:24 |
sarnold | mahdi_ja: so ssh works but sftp doesn't? | 03:24 |
mahdi_ja | sarnold, whit ssh i get this error :Permission denied, please try again. | 03:26 |
sarnold | mahdi_ja: I think solving that will go a long way | 03:27 |
mahdi_ja | sarnold, and how ? | 03:27 |
sarnold | mahdi_ja: check the sshd logs, auth logs, see what errors it's reporting | 03:28 |
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 :) | 03:32 |
=== kallesbar__ is now known as kallesbar | ||
=== jelly-home is now known as jelly | ||
emOne | Are there some default lists of ports that should be closed by default? | 10:39 |
emOne | are there any ports which are already closed on ubuntu server ? | 10:40 |
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:41 |
lotuspsychje | emOne: the attacker is always looking for 24/7 servers with interesting services that are exploitable | 10:42 |
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:44 |
emOne | lotuspsychje: I received an email saying I should do something about my port 111 which is used by portmapper | 10:45 |
lotuspsychje | emOne: running NFS? | 10:47 |
emOne | lotuspsychje: I am not sure. I locked myself out while activating the firewall | 10:48 |
emOne | trying to get back online | 10:49 |
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:43 |
lordievader | weedmic: This sounds like Zabbix | 11:50 |
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. | 11:57 |
vlt | weedmic: Or Nagios/Icinga. | 12:31 |
lordievader | weedmic: Zabbix will nag at you when things hit the fan 😋 | 12:53 |
weedmic | when htop reports "load average = 18.6" and I have 40 cpus, the number is cpu equivalents? t/f? | 13:48 |
nacc | weedmic: load average is about (in some sense) runnable processes, it's not normalized to how many cpus you have | 13:50 |
weedmic | so, 18.6 means about 18 processies are running at the same time on average? | 14:01 |
weedmic | if so, how does one know when the number is high enough to be a concern/worry? | 14:02 |
lordievader | It is not necesarily running. It means that 18.6 cores are busy a 100% of the time. | 14:17 |
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:18 |
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 | 14:24 |
nacc | weedmic: every hardware thread is a logical CPU in Linux; load isn't really core based -- it's logical CPU based | 15:16 |
weedmic | Q | 15:17 |
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:44 |
weedmic | nvm - the real thing i wanted was "cat /proc/loadavg”" | 15:48 |
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:43 |
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:44 |
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:45 |
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:47 |
ahasenack | teward: hm, looks like it stops listening on ipv6: https://pastebin.ubuntu.com/p/McKNnMTBSS/ | 16:48 |
teward | hmm | 16:48 |
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:49 |
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:50 |
teward | fairly sure https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592 is a dupe of this | 16:51 |
ubottu | Launchpad bug 1743592 in nginx (Ubuntu) "NGINX fails to install/upgrade if IPv6 is completely disabled." [Low,Triaged] | 16:51 |
ahasenack | agreed it is | 16:51 |
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:52 |
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:53 |
teward | nor would such an SRU actually *get* to the end users side of things because of how config files're handled | 16:54 |
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:56 |
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:57 |
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* | 16:58 |
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:46 |
tds | axisys: just to check, you're running that netstat command on "remote"? | 19:47 |
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:48 |
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 | 19:49 |
=== Greyztar- is now known as Greyztar |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!