Relevant for the next TT-RSS update:

https://discourse.tt-rss.org/t/some-plugins-are-getting-renamed/2685

plugin host has a priority-based system for hooks now so this stupid hack with adding endless Zs to names is finally no longer needed.
therefore, some plugins are getting de-zz-ified. because tt-rss class loader expects class name for plugins to match plugin directory name, you will need to rename some external plugins after next git update, if you were using them:

af_zz_img_phash -> af_img_phash
af_zz_api_resize -> api_resize_media

bundled plugins are going to rename themselves after git checkout, but you will need to enable them again in preferences -> plugins if you were using them.

af_zz_imgproxy -> af_proxy_http

for plugins that use native plugin storage (not required but that’s where plugin settings are):

update ttrss_plugin_storage set name = 'Af_Img_Phash' where name = 'Af_Zz_Img_Phash'
update ttrss_plugin_storage set name = 'Af_Proxy_Http' where name = 'Af_Zz_ImgProxy'

Several security issues were identified in nginx HTTP/2
implementation, which might cause excessive memory consumption and CPU usage (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516).

The issues affect nginx compiled with the ngx_http_v2_module (not compiled by default) if the "http2" option of the "listen" directive is used in a configuration file.

The issues affect nginx 1.9.5 - 1.17.2.
The issues are fixed in nginx 1.17.3, 1.16.1.

https://vuls.cert.org/confluence/pages/viewpage.action?pageId=56393752

https://www.nginx.com/blog/nginx-updates-mitigate-august-2019-http-2-vulnerabilities/

Today we are releasing updates to NGINX Open Source and NGINX Plus in response to the recent discovery of vulnerabilities in many implementations of HTTP/2. We strongly recommend upgrading all systems that have HTTP/2 enabled.
In May 2019, researchers at Netflix discovered a number of security vulnerabilities in several HTTP/2 server implementations. These were responsibly reported to each of the vendors and maintainers concerned. NGINX was vulnerable to three attack vectors, as detailed in the following CVEs:

• CVE-2019-9511 (Data dribble)
• CVE-2019-9513 (Resource loop)
• CVE-2019-9516 (Zero‑length headers leak)

We have addressed these vulnerabilities, and added other HTTP/2 security safeguards, in the following NGINX versions:

• NGINX 1.16.1 (stable)
• NGINX 1.17.3 (mainline)
• NGINX Plus R18 P1

@murgero said in Open ports in firewall:

This might change in the future though as the project I believe was stated somewhere else that might move away from IPT.

I think Cloudron intends to move to ufw which still uses iptables, see https://forum.cloudron.io/topic/1838/replace-iptables-with-nftables

@imc67
You can open ports but again, it's unsupported. See for an example: https://forum.cloudron.io/post/3278 and then make the rule persistent: https://forum.cloudron.io/topic/1780/cloudron-overrides-iptables-persistent/ (see the last 4 posts in that thread)

@d19dotca said in Bitwarden - Self-hosted password manager:

@necrevistonnezr - He means delete the DNS entry from your DNS service provider itself for the domain. So if you already have bitwarden.domain.com in your DNS listing for your domain, then remove the bitwarden entry and then re-create with Cloudron.

That was not the issue since I did not have a subdomain entry in my DNS settings (I have a wildcard DNS entry). The issue was that cloudron-cli was not able to connect to my cloudron properly (TLS, https issues) for reasons I don't know (I told support about it).

After using cloudron login --allow-selfsigned I was able to build and update the bitwarden...

@girish said in Bitwarden - Self-hosted password manager:

@necrevistonnezr You have to delete the DNS entry manually in the DNS provider. What's hapenned is that the dns already has an entry for the subdomain. Cloudron will never overwrite existing DNS records.

Where am I supposed to delete the DNS entry? Is the "DNS provider" something in the cloudron control panel?

I have no other apps / redirects regarding that subdomain.

Tried with the LTS node version today - still the same error "Domain is in use". Anyone have an idea why?

Tried updating the bitwardenrs-app today to its current domain; usually it would just install (and upgrade) the app. Today I got the following error:

➜ cloudron install
ERROR (node:9463) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. [ internal/process/warning.js:27:3 ]
Location: bit
ERROR Failed to install app. Domain 'bitwarden.domain.com' is in use [ /Users/user/.nvm/versions/node/v12.7.0/lib/node_modules/cloudron/src/helper.js:68:29 ]

Yep, the big ones are all backup logs. More than 1,500 files....
Can we at least compress them?

I have 1.5 GB of logs under /home/yellowtent/platformdata/logs/tasks:

  123,8 MiB [##########]  491.log.2
  119,6 MiB [######### ]  498.log.2
  113,5 MiB [######### ]  479.log.2
  111,6 MiB [######### ]  482.log.2
  109,9 MiB [########  ]  484.log.2
   94,7 MiB [#######   ]  487.log.2
   80,2 MiB [######    ]  489.log.2
   66,9 MiB [#####     ]  478.log.2
   66,4 MiB [#####     ]  452.log.2
   62,3 MiB [#####     ]  467.log.2
   61,1 MiB [####      ]  465.log.2
   58,9 MiB [####      ]  477.log.2
   57,7 MiB [####      ]  457.log.2
   55,8 MiB [####      ]  462.log.2
   55,6 MiB [####      ]  445.log.2
   53,8 MiB [####      ]  460.log.2
   48,7 MiB [###       ]  455.log.2
   40,8 MiB [###       ]  472.log.2
   36,3 MiB [##        ]  475.log.2
   30,5 MiB [##        ]  470.log.2
   18,0 MiB [#         ]  394.log.2
   11,7 MiB [          ]  740.log.2
   10,5 MiB [          ]  331.log.2

Is that normal?