Posts made by lucidfox

i can confirm that the order of the steps @onlybro describes work to enable video posting. so i guess including the config line by default as @robi suggests, would make it work for everyone?

@onlybro it worked from the web interface initially, but now only from a client app

@onlybro yeah, you need to add that to the config. here's a screenshot for reference - Screenshot_20210410_225929.jpeg

but as i mentioned on the other thread, this doesn't seem to work for me now, in order to create video posts.

@onlybro i had to reinstall the app, and tried to do the same steps. but for some reason i'm not able to post videos now from a browser.

the funny thing is that posting videos from the fedilab app on android works. i guess the app is just not ready for prime time yet?

@onlybro i'm not sure what the reason for it not working for you might be. you could perhaps try restarting the app if you haven't already, increase the ram allowance, and try creating the post from a different browser. the file size of the video could also be a factor.

so just to update, I got the video working by adding the below line to the env.production (turns out it was just a syntax error ) and then running 'php artisan config:cache' in the terminal -

MEDIA_TYPES=image/jpeg,image/png,image/gif,video/mp4,video/mpeg,video/3gpp,video/quicktime

instagram import still isn't working for me (this might be a deal breaker for people looking to move over). and the way the federation works doesn't seem to allow you to find people and posts on other instances easily yet.

@nebulon i upped the RAM allowance to 1.24 GB, but this was not based on any testing and was just to see if it works.

i like the look of the app, and the fact it is it a federated alternative to instagram. but at the moment, especially without the video posts working, i don't know how much real world use it has. and that's a pity really.

increasing the RAM seems to sort out the errors above (unless it's just a coincidence).

i'm unable to create video posts videos or import from instagram, after adding the below to the config file:

MEDIA_TYPES="image/jpeg,image/png,image/gif,video/mp4"

IMPORT_INSTAGRAM=true
IMPORT_INSTAGRAM_POST_LIMIT=100
IMPORT_INSTAGRAM_SIZE_LIMIT=5000

I'm trying to get Pixelfed working, but there seems to be a few glitches.

I think federation is working, because I'm able to follow:
doodlemania@pixels.thedoodleproject.net and girish@pixelfed.social.

But the Discover page (/discover) is blank and also the following errors are being generated on the failed jobs page -

Anyone have ideas or tips on how to get it to work?

@p44 thanks, it works great.

@p44 i don't use it anymore. i've switched to a storage vps on alphavps, with a minio backup.

@robomod thanks for the tip, i might just wait for the next release before i try to use it then.

@p44 i just followed the one in the cloudron docs (and also the hetzner docs).

cloudron:
//<server>/<remote_folder> /backups_cifs cifs uid=yellowtent,gid=yellowtent,user=<user>,pass=<pass>,iocharset=utf8,x-systemd.automount 0 0

hetzner:
//<username>.your-storagebox.de/backup /mnt/backup-server cifs iocharset=utf8,rw,credentials=/etc/backup-credentials.txt,uid=<system account>,gid=<system group>,file_mode=0660,dir_mode=0770 0 0

@robomod that would be brilliant. so the android app wouldn't work if you install it in a LAMP app?

@p44 sometimes in cloudron it would say 'this is not a cifs mount' or something similiar. even though it seemed to have been mounted properly, and showed up when checking via ssh. it could just be something to do with mounting it incorrectly though. i figured it was not worth troubleshooting, because of the slow speeds.

@p44 I only have the one cloudron to backup at the moment, but I'd imagine you can use the same token or create other buckets and tokens on the same minio server.

so just to update my results here - i tried a hetzner storagebox, but the cifs storage mount was having some stability issues. and it was so painfully slow as to be practically unusable.

so i switched to another option that i've seen mentioned in the forums here, which is to backup to a second cloudron using minio. and i'm happy to report that it's working fine. using an alphavps storage vps it's actually even cheaper, and it's quite convenient to have a further backup if needed.

has anyone got this working? would love to use it on cloudron.

@girish I was thinking potentially to use syncthing with volumes, and then use filestash for web access, sharing etc.

Nextcloud is great, but its a bit of a slow giant that's resource intensive. It tries to do a lot of things and doesn't do the core function of syncing files very efficiently.

any updates on filestash? seems like it would be a great light weight alternative to nextcloud.

@girish thanks for that, it worked. i'm not sure how useful the password protection is in practice, at least in my case, because the receiver of the file pizza link would also need to sign in (and not just the uploader). i've gone back to using file pizza without having to login. wondering if this a security risk in anyway?

I'd like to add the password protection to file pizza as well. Seems like I might be missing an obvious setting, but how can can the proxyauth be activated?

@atrilahiji that would be brilliant! I don't have any packaging skills, but happy to help with testing or anything else.

@jdaviescoates mmm... that's a pity. hopefully they'll add other authentication options soon.

Any updates on getting Outline on to Cloudron?

I've been playing around with a hosted version, and have to say Outline seems very intuitive and easy to use, compared with some of the alternatives (on Cloudron and otherwise).

@marcusquinn I don't have any regulatory needs. But it might make sense to reach back into the past, to a reasonable extent, in case a user accidentally deletes files and doesn't realise for a bit.

So just to update... I installed an unstable version of Vikunja as a custom app, because some bugs to do with the Todoist migration were meant to have been resolved. The Todoist importer worked a bit better, but still threw up errors. Apart from that the app is working pretty flawlessly from what I can tell. Would be brilliant to have it added (perhaps v1 would be the right time).

Thanks everyone for sharing your suggestions and insights (this is a very special community, and it's nice to be part of it). I've decided to try encrypted rsync to a Hetzner StorageBox via a CIFS mount. Others seem to be having trouble maintaining the mount with Hetzner Storage Boxes, so hopefully that doesn't happen too often. Even though there might be latency issues, I think this would be better than using a Netcup NFS mount, just so that the backups go to another provider from what the VPS is on.

@girish It would great if Cloudron could add more robust and nuanced backup options at some point. But I can understand that it's not priority at the moment (y'all are doing a great job with Cloudron).

@marcusquinn Your thinking on using the VPS snapshot does make a lot of sense. In my case most of the app data is on an Netcup NFS mount, so snapshoting the server wouldn't be very useful (I doubt the addon storage is included). So I've sort off flipped that on it's head, and will try doing daily rysnc backups (retained for a week) and then weekly automatic snapshots on the Hetzner Storage Box (you get a certain number free, depending on storage capacity). This doesn't have the effect of conserving VPS resources, but should extend the backup range without adding to storage costs.

I have Cloudron installed on a Netcup VPS, and am having trouble setting up a reliable backup strategy that works on a consistently while being cost effective.

Some background info - backup size for the entire platfrom is currently about 850 GB, with most of the data being contributed to by user Nextcloud data. Automatic backups are currently scheduled to run once a week, and the retention policy is set to one month (any opinions on whether this is to lax?).

I would like to use a different service provider for backups (different vendor and geographic region) and also have have encryption enabled, so that the storage provider doesn't have to be trusted.

Initially, the backups were rsync to Wasabi. This worked pretty flawlessly. But Wasabi charge for deleting data, so even though the storage costs are very reasonable, the overall costs quickly become unreasonable.

Then I switched to Backblaze, they don't charge for deleting data, but using rsync causes there to be a lot of API calls, with costs quickly adding up (though not as extremely as Wasabi).

So I switched to tgz backups. This I guess is sub-optimal for having to transfer so much data every time (even though bandwidth is not at a premium or particularly limited). This worked OK a few times after increasing memory limits (up to over 6 GB), but I'm now getting task timeouts and am unable to successfully backup. I've played around with the memory and upload part size settings but still not luck, getting it stable.

Is there anything obvious I'm missing? How do you do backups? Any advice in getting this right would be much appreciated. Ease of admin, cost, elasticity of storage to the actual size of the backups, and security would be the main considerations. Would setting up a separate Minio backup server and using Rsync be a good solution?

I've got Vikunja installed as a custom app (would love to see it published to the Cloudron app store as well).

One of the highlighted features is the ability to import from Todoist, but there's no way to do this through the interface. I asked in the Vikunja matrix chatroom, and someone suggested all the details on how to achieve this would be in the config.yml file. I've looked at this file in my install, but can't see any such section or info. Has anyone figured out how to migrate from Todoist?

Ok, thanks much for the update. Wish I could help with the packaging, but I've got zero skills or experience to contribute to that. Would be amazing to have this on Cloudron at some point, it seems to be the most promising Google Photos alternative.

Any updates on this... would love to have this on Cloudron. Don't mean to nudge, just curious how it's going with packaging.

Update: It appears to be an instance of Syncthing with a particularly long filepath that is causing the backup issue.

That does seem to make sense. I just wanted to mention the second instance, as the default port wasn't an option.

@BrutalBirdie thanks for the links, i'll check them out. nextcloud was actually the app that was most critical to backup, so i did a manual backup of that and it worked fine.

@nebulon we do have encryption turned on, i'll try to turn it off to see if that helps. an encrypted backup would of course be more desirable but perhaps another non-s3 storage option would work better for this.

thanks for the tips. i'll do manual backups and check the logs to figure out which app or file is causing the snag.

Cloudron was backing up fine to Wasabi until 4 days ago, but it has been throwing up an error when attempting to upload a snapshot since then. This happens whether a manual backup is triggered, or it is run according to the backup schedule.

The region that this Cloudron instance (v.5.6.1) is being backed up to is Wasabi EU Central 1, and the storage format used is rsync.

The Error Message: Your key is too long HTTP Code: KeyTooLongError

I tried to change the API keys, but that didn't help. Manual created backups of individual app still seem to working fine. Any ideas on how to solve this?

@nebulon No, the port gets reset to the one defined on the Cloudron dashboard when restarting the app (and there is only 1 listener listed on Syncthing). But the connection to the syncthing instances on my other devices work fine after that, even though they didn't initially on that port.

Changing the Sync Protocol Listen Addresses in the Syncthing settings 'Connections' tab to 'default' seems to have done the trick.

I'm trying to run a second instance of Syncthing on a server (installed on another domain). I set the sync port in Cloudron to a non-standard port '22846' while setting up the second instance, but it just isn't able to connect to other devices. Is this because other ports apart from '22000' are blocked? In the app config page it says 'Port over which syncthing will exchange data (do not disable) (1024 - 65535)'

syncthing on my desktop reports these errors:
tcp://x.xx.xxx.xx:22846
No connection could be made because the target machine actively refused it
tcp://default:22846
no such host (11:15:21)

syncthing on cloudron reports this error:
tcp://xxx.xxx.xxx.xxx:22846
no route to host (11:18:17)

Any help figuring this out will be much appreciated. Thanks.

Yeah, I was hoping to get a picture of the storage used by a user or usergroup across all apps on Cloudron. Apart from companies or single user installs of Cloudron, the thinking was that enabling groups of people to share a server and switch to self hosted open source
software would involve having insight into the main variable resource - the storage - in order for the cost sharing to be transparent.

I understand that's it's not feasible to implement, so will need to think of other community models for resource sharing. Mounting a users own NFS storage is an option, but Cloudron apps are restricted to a single storage location per app instance. Perhaps users mounting their own external storage in an app like Nextcloud is an option.

Any thoughts on a clean model for this kind of resource sharing scenario? This seems to me an important consideration for "regular" users of Cloudron, who might want to get together in order to make switching over from Google etc. financially viable.

I think it might be beneficial to have some stats or tracking mechanism for the server resource usage of users or usergroups in Cloudron, as this would enable non enterprise and multiple user servers to share hardware resources fairly The use case scenario here would be communities or groups of people who want to share, and spread the word on self hosting open source applications.

The biggest variable in my mind, in terms of calculating costs, is the amount of storage a user or usergroup uses. Is there someway to track this, so that a percentage share of storage provisioned can be worked out?

I've read elsewhere that Netdata might be the way to go, to get detailed info on server resource use. Would this work for seeing a Cloudron user's share of mounted NFS storage for instance? Or is this something that is better accomplished from inside specific apps, like say Nextcloud.

Never used Git, will keep that in mind for reporting any issues that I might come across with Cloudron apps!

Now that I know that shared volumes is what I'm after (I thought it might be different somehow if it was a specific permission for an app to read data outside of it's docker container), how can I set up and use a shared volume if it's not exposed on the interface? Or is this something that's not trivial and best left alone till it's stably implemented?

@mehdi Thanks! That worked a treat. Setting the right ffmpeg path fixed it and playback is working with and without the transcoding options disabled.

@girish thought I'd flag this for you. As having the ffmpeg path set up right by default, might be useful to make it more seamless for other noobs looking to run Jellyfin on Cloudron. Also, would it be possible to share folders between Syncthing and Jellyfin? Maybe this would be easier to achieve than more complex shared volumes?

@mehdi I don't have Node or Docker installed (I don't have any dev experience and am quite new to server management), so I figured spinning up Ubuntu in Virtualbox would be the easiest way to start using CLI tooling.

Yeah, the playback error is really odd. I even deleted and reinstalled Jellyfin, but that doesn't solve it. The FFMPEG path on the transcoding settings page in Jellyfin is empty, and I'm not able to locate it anywhere on the server when looking around with Filezilla. The default FFMPEG path is apparently - /usr/bin/ffmpeg.

I tried files encoded in h.264 (with AAC audio) in an mp4 container, as I figured these would be the most universal formats that probably wouldn't require transcoding.

Any help figuring this out is much appreciated.

I managed to load a couple of movies into Jellyfin via SFTP, but they don't playback on any connected client devices or browsers because of a playback error. On investigating this it seems it's because FFMPEG (and the FFMPEG probe) aren't installed or can't be found by the app. I'm a bit confused because this is meant to be part of the default Jellyfin package? Do I need to install FFMPEG seperately?

I haven't had a chance to install 'River' yet, because I'm on a Windows machine and a CLI install from Linux seems the easiest way to install the app. Still quite keen to give it a go once I get a virtualbox going. @mehdi does river come with FFMPEG preconfigured?

@girish Thanks for the detailed response on the issues and limitations surrounding shared volumes. I'm basically just looking for anything that is an upgrade on SFTP and could be an easy way to store and access media across apps on Cloudron that support using shared volumes. And if possible to achieve this without disappearing down a trouble shooting rabbithole myself.

I would be happy to try using a volume that is shared between Jellyfin and Syncthing, if that's something that would work? Syncthing seems to have a good reputation for transferring larger files reliably, and has peformed pretty well on a few test I've tried.

I did read about the unreliability of Nextcloud external storage and issue with Lychee and creating it's own database (which I guess makes it a less desirable all purpose photo manager alternative to Google Photos).

@mehdi @jdaviescoates Thanks for the heads up on that. It sounds like it ticks a lot of the boxes. Will give it a go, and update how I get on here.

Anyone have any thoughts or ideas on this? Perhaps some kind of solution using syncthing?

I recently got Cloudron running on a Netcup VPS with NFS storage mounted (also provided by Netcup). This works great for moving individual app data for most apps off the main server, but for the Jellyfin app the Docker containerization of data seems to stop there being anyway to actually get the media into the app? A shared volume that could be 'seen' by different apps would be ideal, and this would also be great for something like sharing photos between Nextcloud and Lychee. Is this a feature that is going to be rolled out soon? I read elsewhere that something like this was planned for an earlier Cloudron release.

I've been looking for possible work around using symlink or hardlinks, or mouting external storage in Nextcloud, but none of the options seem to really be viable. Rclone with a cloud provider seems to be a popular solution for Jellyfin, but I'm not sure how this would work? Any suggestions on a workaround that wouldn't break how Cloudron's backups and default behaviour works would be greatly appreciated. I have almost no experience with managing a server, so the less tinkering the better!