huh for some reason in my last session I did not see the search field but there is one. (Maybe I was just blind ) [image: 1641417954001-094213ff-47fe-41f3-b452-a341a216719f-grafik.png] I take it back, please don't throw stones

logrotate is run via the system cron. You can check these: /etc/logrotate.conf should contain the line include /home/yellowtent/platformdata/logrotate.d in the very end. The file /home/yellowtent/platformdata/logrotate.d/platform should contain /home/yellowtent/platformdata/logs/turn/*.log As for cron configuration, systemctl status cron should say Active/running. There should also be a file /etc/cron.daily/logrotate . Other than that, it can only mean that turn server generated a massive amount of logs in a single day (seems quite unlikely but who knows). Does it rotate if you run logrotate manually? - Run /usr/sbin/logrotate /etc/logrotate.conf ?

@mehdi good catch, will fix!

@hamann ah actually this bug is already fixed with https://git.cloudron.io/cloudron/box/-/commit/cefbe7064f4c7b31fb93bbf7ed85bf916aa5cf39 but pending a release. For the meantime you could tweak the file manually at /home/yellowtent/box/src/apps.js and then systemctl restart box or enable the mailbox for that app temporarily.

@rmdes I ended up setting up a local backup for Cloudron and use RClone to handle the backup. I've used RClone for years with no issue, and since going this route, no issues with my Cloudron backup.

@d19dotca thanks man, I’ll look in to your links and also take a look at the app-dev flag of people and see what I figure out! Thanks!

@zezaung could this be related to your DNS issue from your other forum thread? Which certificate provider have you configured?

@girish ah i didnt even notice bevause of all the 4j notices my eyes where too open thx for looking at this anyway

@girish thank you, the output is different now, so I hope that will work. I took that API call from my forum request earlier, but I guess there was a misunderstanding the API call example was for the specific domain, not to update them all. Thanks for your assistance!

@nebulon said in Cloudron.io 2FA Problem & LDAP Question: To be clear, each Cloudron requires one subscription. We have had various ideas around how to team up multiple servers into one Cloudron, but that is not implemented, once that is done, we will adjust our pricing scheme to match this "node" system then. For me its not even to "team up". I tought about the idea to record the coachings and share it (yt) to marketize myself, my customers pages and cloudron aswell. I still need to blur something but i just dont want to use my normal acc^^ But still be able to push/pull a install of my server to a customers server after i got him far enough to do it without destroying it (or "deleting" the internet)^^

@kyleh2946 hm that seems quite specific to your proxmox setup. Not sure I can easily help here. Do we have other users on proxmox here?

@jdaviescoates ah yes then this most likely was the issue with the unbound anchor file. See https://docs.cloudron.io/troubleshooting/#recovery-after-disk-full

Mostly you can build your own app packages for this. You could look up various different tech stack packages as referenced at https://docs.cloudron.io/packaging/cheat-sheet/#examples

@nebulon said in Cloudron CLI login command results in an HTTP 404 error with "Cannot POST /api/v1/developer/login" message: You probably have to update the cli tool, since the /api/v1/developer/login route was long deprecated and finally removed from the server side. @girish said in Cloudron CLI login command results in an HTTP 404 error with "Cannot POST /api/v1/developer/login" message: For reference, the latest CLI version is 4.12.8 (Use cloudron --version to see current version) So I checked the version of Cloudron CLI finally and it seems I am indeed running 4.12.8... <username>@<computerName> ~ % cloudron --version 4.12.8 However, I ran the command cloudron login again and now it suddenly works. So I'm not sure, maybe I had ran the update (I know I did for a fact) but perhaps it wasn't recognized until my computer had restarted over the holidays here. Something strange, but it's all good now it seems.

@mehdi thanks for reporting, this is fixed now. Next time a separate thread might be better to track those things if possible.

@omen OK, I figured out how configure Fastly now... Please configure it like below: Enable TLS - Yes Verify Certificate - Yes Certificate hostname - In my case, it is wildcard. But since you use the 'manual' provider, the hostname is subdomain.example.com. SNI hostname - this is subdomain.example.com. With the above settings, fastly serves up pages fine on http. [image: 1640323796482-c787fbfb-57bb-4793-a100-3da1015ba6a5-image-resized.png] One thing to remember is, because you are using "manual" DNS provider, Cloudron requires "http" callbacks for Let's Encrypt to work. I am not sure how this works in fastly, does it allow you to have some URLs that are not "cached" ? I guess one way is to call the Cloudron app subdomain as "website.domain.com" but the domain in fastly should be something else like "realwebsite.domain.com" (meaning, name it different). This way, manual setting on Cloudron can continue to use HTTP reliably to get certificates. If you want the domain names to be same, you have to use one of the automated DNS providers in Cloudron.

@joesitsolutions said in Restoring app from backup?: I have the .zip file. Cannot figure out why I keep getting "backupFolder path is protected" You can only create backups to specific paths on the server. Many of the paths are "protected" to make sure that the folders won't get overwritten by updates or are used by the system. This is just a hardcoded list of paths: const PROTECTED_PREFIXES = [ '/boot/', '/usr/', '/bin/', '/lib/', '/root/', '/var/lib/', paths.baseDir() ]; (the baseDir above is /home/yellowtent/). You cannot create backups in subdirectories of the above paths. I understand you are using restore here though and not backup The restore logic uses the same validation logic for paths and you have copied the backup to under /home/yellowtent/. Instead, copy the backup in some path like /mnt/backups/ or /srv/backups/ and try to restore, that should work.

This got sorted out by @ntnsndr by contacting linode support. The VM had to be rebooted after linode unblocked port 25.

It's back online now! Agree about having a second source. Ideally, we can have some self-hosted docker registry which is used as a fallback for such situations.