| MonkZ | Hiho, is there a reason that the "lts" alias still points to 18.04 on https://cloud-images.ubuntu.com/ ? See "lxc image list ubuntu: lts" | 06:54 |
|---|---|---|
| Orcs53_ | Hi everybody! I have a question regarding configuring a simple routing firewall. I plan to use Ubuntu Server 20.04, and ufw, and I have found a good example for the configuration (see "Full example" in https://manpages.ubuntu.com/manpages/focal/en/man8/ufw-framework.8.html). However, in this example, it is mentioned "Your firewall will undoubtedly | 07:22 |
| Orcs53_ | want to be less open.". I would like if someone could discuss any further steps for hardening the configuration seen in this approach. Thanks! | 07:22 |
| icey | jamespage: https://github.com/openstack/taskflow/commit/598e09fb062daed36fd4f10943ce9b4381843c9e is the change I was referring to - it does seem to be limited, functionally, to postgres | 12:39 |
| icey | jamespage: might be worth looking at using the sqlalchemy built in JSOn type instead | 12:40 |
| icey | JSON | 12:40 |
| Orcs53_ | Hi everybody! I asked this question earlier, I am still keen to here back if anybody can help. I have a question regarding configuring a simple routing firewall. I plan to use Ubuntu Server 20.04, and ufw, and I have found a good example for the configuration (see "Full example" in | 12:49 |
| Orcs53_ | https://manpages.ubuntu.com/manpages/focal/en/man8/ufw-framework.8.html). However, in this example, it is mentioned "Your firewall will undoubtedly want to be less open.". I would like if someone could discuss any further steps for hardening the configuration seen in this approach. Thanks! | 12:49 |
| icey | jamespage: except, that introduces a behaviour change for newer databases where they actually have a JSON datatype :-/ | 12:56 |
| Odd_Bloke | MonkZ: Ubuntu generally only starts recommending upgrading to the latest LTS after its .1 release, it may be something to do with that. | 12:58 |
| Odd_Bloke | rcj: Do you happen to know ^? | 12:58 |
| icey | it does pass it's tests jamespage... | 13:02 |
| ubone | my hostname was something random - not the domain i use for postfix - now i see thunderbird warning because of it (via dovecot?), is make-ssl-cert generate-default-snakeoil the command to redo the postfix/dovecot certs ? | 13:10 |
| rcj | MonkZ: Odd_Bloke is correct. The LTS alias moves to the latest LTS release around the time of the .1 release. | 13:12 |
| rcj | https://git.launchpad.net/simplestreams/tree/tools/ubuntu_versions.py#n24 is the code that creates the stream data which lxd reads for these aliases | 13:13 |
| rcj | Odd_Bloke: ^ FYI | 13:13 |
| MonkZ | thanks that information is helpful! | 13:13 |
| lotuspsychje | firewall | Orcs53_ | 13:29 |
| lotuspsychje | !firewall | 13:29 |
| ubottu | Ubuntu, like any other Linux distribution, has built-in firewall capabilities. The firewall is managed using the 'ufw' command - see https://help.ubuntu.com/community/UFW | GUI frontends such as gufw and ufw-kde also exist. | An alternative to ufw is the 'iptables' command - See https://help.ubuntu.com/community/IptablesHowTo | 13:29 |
| lotuspsychje | Orcs53_: see also #netfilter and ##networking for firewalling topics | 13:30 |
| Orcs53_ | Thanks for the responses | 13:35 |
| Orcs53_ | I am familiar with ufw and would like to discuss this firewall tool specifically, I assume this fits the topic for this channel. | 13:36 |
| avu | is that factoid out of date or is 20.04 really still using iptables? | 13:36 |
| Orcs53_ | lotuspsychje, Thank you I will note these channels and also seek help there. | 13:37 |
| lotuspsychje | avu: the wiki seems to be edited in 2020 think that might still be valid then | 13:38 |
| avu | lotuspsychje: weird, wouldn't have imagined Debian stable and CentOS/RHEL to be ahead of Ubuntu in such a thing :) | 13:39 |
| mason | avu: Ubuntu 20.04 ships nftables. | 15:49 |
| mason | avu: And there's a compatibility layer, so it's relatively safe to still talk in terms of iptables. | 15:50 |
| mason | avu: Finally, there's a vast amount more iptables still deployed. | 15:50 |
| keithzg[m] | Damn, the problem hadn't occurred for a few days but it just happened again, the 18.04 server I have set up as a primary storage pool (serving via NFS, SMB, and SSHFS, and hosting among other things user home directories used on other servers on the LAN) had file i/o on its BTRFS pool (raid10, 4x4TB HDDs) slow to such a crawl things were failing hard, but with nothing in the logs pointing any cause, just every file | 18:34 |
| keithzg[m] | operation suddenly taking way too long. This continues to stump me :( | 18:34 |
| sarnold | keithzg[m]: I have two thoughts (a) use perf top to try to determine what is taking a long time and see if you can do something about it (b) blindly try what helps me on my zfs system when it's unhappy at having to access way more files at once than linux was intended to handle -- echo 2 > /proc/sys/vm/drop_caches | 18:42 |
| keithzg[m] | sarnold: I've tried stuff along the lines of (a) but it just seemed to be normal routine i/o like Dovecot deliveries that were perpetually hanging, no i/o actually being used and they couldn't be killed :(. I should probably redouble my efforts along those lines though, and hadn't used `perf-top` yet. Never even heard of (b), I'll definitely give that a shot next time this happens, interesting! (Certainly sounds | 18:52 |
| keithzg[m] | less troublesome than wholesale rebooting, which has been the only 'solution' so far.) | 18:52 |
| sarnold | keithzg[m]: yeah, perf top gives you a chance to figure out what exactly is taking forever. it might or might not lead to a better solution than dropping caches :) but not even knowing why it's sad is too much to bear | 18:55 |
| keithzg[m] | sarnold: Noted and very true! | 19:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!