If you are using Ghost on Cloudron for your blog, you are required to setup a mailgun account in order to have transactional email which lets people who wish to subscribe to your blog receive a "magic link".
For some strange reason, Mailgun disbaled the account before it was ever used. An alternative blogging platform will be needed. What on earth could have prompted them to ban something that has never been used?
9.2.14 is the latest Manticore version.
https://github.com/manticoresoftware/manticoresearch/releases/tag/9.2.14
Here are the improvements since Manticore was first requested:
https://github.com/manticoresoftware/manticoresearch/compare/9.2.14...6.0.4
@girish Perhaps the Nextcloud Talk High Performance Backend as well as the Elasticsearch could be installed together onto the same server, somehow.
There is also Manticore:
https://forum.cloudron.io/topic/9753/manticore-search-oss-fast-database-for-search-alternative-for-elasticsearch
Is there a neat trick to determine which of Hetzner's locations would provide the best latency for Nextcloud Talk High Performance Backend?
@jdaviescoates Everywhere, basically. Would it be possible to setup Nextcloud so that people could inhabit and use it without ever seeing each other's emails?
If you are on a nextcloud and you look at the Users list, even as a regular user, you will probably see everybody's email listed there.
There might be some environments where you would not wish participants to have their emails disclosed to the rest of the nextcloud.
@andreasdueren said in Nextcloud Signaling Server / Highperformance Backend Installation Guide:
@bvxzee I thought about packaging the HPB for cloudron but eventually decided against it because it would negate most of the benefits. Cloudron has pretty strict firewall restrictions which make the built in turn-server so unreliable to begin with. I can highly recommend this installation: https://github.com/sunweaver/nextcloud-high-performance-backend-setup
I'm using it very successfully on a separate VPS.
Thanks. So it looks like a dedicated server will be needed to setup the HPB. What would be the minimum spec for the maximum increase in performance for such a server? What are the features that we would want to find, so that we can be cost effective? If we run several nextclouds, could we setup on HPB and then use it for all the different nextclouds? GNU/Linux Debian based or is GNU/Linux Debian a requirement? For example, would an Ubuntu VPS do as well?
@archos Thanks.
What about for new people who join the nextcloud. When they see the other users, won't the other usernames as well as their emails be listed?
I think seeing the usernames would be expected, but not their email addresses, too.
@girish @andreasdueren setup something to help with the NHPB (Nextcloud High Performance Backend).
https://forum.cloudron.io/post/76397
What is the latest on this? Might Cloudron be able to help ease setup?
Distrotube gave a self-restrained analysis on this.
https://odysee.com/@DistroTube:2/ubuntu-ditches-gnu-core-utilities:9
He notes that the Rust community is politically active and takes a position that technology is political.
By default, when somebody joins Nextcloud, everybody's email address is visible. I don't know whether this is in accordance with the GDPR, but is there an easy way to set the default to not visible?
One user mentioned this trick, but it is hard to find that file/folder using the file browser.
Edit this file more less in the line 308: “NCrootFolder”/lib/private/Accounts/AccountManager.php
Where it says:
self::PROPERTY_EMAIL =>
[
‘value’ => $user->getEMailAddress(),
‘scope’ => self::VISIBILITY_CONTACTS_ONLY,
‘verified’ => self::NOT_VERIFIED,
],
It should say:
self::PROPERTY_EMAIL =>
[
‘value’ => $user->getEMailAddress(),
‘scope’ => self::VISIBILITY_PRIVATE,
‘verified’ => self::NOT_VERIFIED,
],
The problem is that the file might be overwrited in an update.
I think this should be private by default, or at least, configurable.
This software is now on 4.5.0 Beta. Here are the changes since when the application was first requested:
https://github.com/sabnzbd/sabnzbd/compare/3.1.1...4.5.0Beta2
NZBGet is often used in combination with other Usenet tools like Sonarr and Radarr. It can integrate seamlessly with these applications to automate your Usenet.
Main Page: NZBGet Official Website https://nzbget.com/
Git: NZBGet GitHub Repository https://github.com/nzbget/nzbget
Licence: GNU General Public License (GPL)
Docker: Yes
Demo: Screenshots and Documentation https://nzbget.com/
Summary
NZBGet is a free, open-source Usenet downloader designed for speed and efficiency. Written in C++, it provides a lightweight yet powerful solution for downloading files from newsgroups. With a web-based interface, multi-server support, and advanced features like fast deobfuscation and post-processing scripting, NZBGet is an excellent fit for Cloudron users looking to expand their self-hosting capabilities with a resource-efficient Usenet client.
Notes
Why I like it: NZBGet stands out for its exceptional performance and low resource usage, making it ideal for running on modest hardware or alongside other Cloudron apps. Its active development and community support ensure regular updates and reliability, which is crucial for self-hosting enthusiasts.
Concerns: The web interface might feel less intuitive for beginners compared to alternatives like SABnzbd, though its superior efficiency justifies the slight learning curve.
Alternative to / LibHunt link
NZBGet serves as a strong alternative to SABnzbd, a popular Usenet downloader that’s heavier on resources due to its Python-based architecture. For more options, check out LibHunt Usenet Downloaders.
https://forum.cloudron.io/topic/4090/sabnzbd-binary-newsgroup-reader
(I used AI to help create this App Request.)
It says failed to send magic link.
If your ghost instance is at:
what should your other settings look like?
You have to enable email masquerading in settings etc but the whole thing is a bit complex.
@nebulon This was the problem. Porkbun had been left with its "pixie" default settings. Once these were deleted, the installation went perfectly smoothly, as usually happens with Cloudron.
Thanks
(I always forget how to mark these as solved. It is in thread tools somewhere...)
It works ok on a subdomain but won't install onto the bare one, for example:
No Problem: nextcloud.example.com
Problem: example.com
Does Cloudron have support for this yet?
For example, if we have only one server and run a single instance of Cloudron on it, could we run several domains from there?
Server: from e.g. linode
Cloudron: my. example.com
Nextcloud instance one: nextcloud.example.com
Nextcloud instance two: nextcloud.otherdomain.com
Or more simply just running the nextcloud instances on bare domains:
How does it work? You run a client program on your computer, which talks to one or more storage servers on other computers. When you tell your client to store a file, it will encrypt that file, encode it into multiple pieces, then spread those pieces out among various servers. The pieces are all encrypted and protected against modifications. Later, when you ask your client to retrieve the file, it will find the necessary pieces, make sure they haven’t been corrupted, reassemble them, and decrypt the result.--
Syncthing
Nextcloud
Resilio Sync
BorgBackup
GlusterFS
Ceph
Restic
Seafile
