Does anyone know if dockge allows you to directly connect to a git repo to pull compose files?

This is what I like most about portainer. I work in the compose files from an IDE and the check them into my self hosted git repo.

Then on portainer, the stack is connected to the repo so only press a button to pull the latest compose and there is a check box to decide if I want the docker image to update or not.

Works really well and makes it very easy to roll back if needed.

Bitwarden let’s you upload files (key files) and save all you passwords.

Use aegis, export the keys and then reimport them every time you switch. Trusting your second factor to a cloud is a disaster waiting to happen.

If you want to get fancy setup your own cloud server (nextcloud, Seafile, owncloud etc) and set the backup folder for aegis to the self hosted cloud for easy restore every time you switch ROMs.

FWIW collabora and open office can integrate with other clouds like Seafile and owncloud Infinite scale. So even without NextCloud it can be used. It can also be used stand alone.

I don’t remember all the details. They never went closed source, there was a difference in opinion between primary devs on the direction the project should take.

Its possible that was related to corporate funding but I don’t know that.

Regardless it was a fork where some devs stayed with owncloud and most went with NextCloud. I moved to NextCloud at this time as well.

OwnCloud now seems to have the resources to completely rewrite it from the ground up which seems like a great thing.

If the devs have a disagreement again then the code can just be forked again AFAIK just like any other open source project.

If I understand it correctly, layering an application is no more dangerous than a regular install on a non atomic os. In other words, every piece of software you have installed on normal fedora desktop is not containerized, if it’s software you were going to install anyways, layering it is the same as before (albeit significantly slower than install and update).

But that means that you get great benefits because 99% of your software packages are properly containerized

I only read the beginning but it says you can use it for private deployments but can’t use it commercially. Seems reasonable. Any specific issues?

I have no problem supporting devs but locking what should be core features behind a paywall in unacceptable for me.

I mean software that’s actively being developed can’t be called DOA. Even if it’s garbage now (and I don’t know if it is) doesn’t mean it can’t become useful at a future date.

Its not like a TV show where once released it can never be changed.

Oh never mind, I saw this finding announcement for 6M and assumed it was the same company. Looks like they have many corporate investors…doesn’t inspire too much confidence.

Although they are still using the Apache 2 license and you can see they are very active in github. It does look like it’s a good FOSS project from the surface.

https://owncloud.com/news/muktware-owncloud-gets-another-round-6-3-million-funding-releases-owncloud-6-enterprise-edition/

Ya it was bought by kiteworks which provides document management services for corps (which explains why that mention traceable file access in their features a lot).

That being said, they bought them in 2014 it seems and it’s been a decade now Correcting: they were bought very recently, they have been accepting corporate funding for more than a decade however. That’s not bad in and of itself.

Thank your for providing first hand perspective. I’ll probably try to spin up a docker deployment for testing.

I don’t really plan to use many of the plugins since I think that was the down fall of NextCloud. Trying to do everything instead of doing it’s core job well.

Also looking through some of the issues and comments on github about no plans to implement basic features (file search on the android app) does not inspire confidence at all. One of the reasons I’m hoping the OwnCloud rewrite is good.

Did not know this. Thanks!

Looks like Kiteworks invested in OwnCloud in 2014 and they still seems to be going strong with the OSS development which is a good sign.

This probably explains why there are so many active devs on the project and how they got a full rewrite into version 4 relatively quickly.

Already seems to have more features than Seafile.

I know, I did as well.

The point of the post is that there is a very active full rewrite of the whole thing trying to ditch all the tech debt that NextCloud inherited from the OG owncloud (php, Apache etc)

I had NextCloud on a Ryzen 3600 with NVME zfs array. While faster that my previous Intel atom with HDD + SSD cache, Seafile blows it away in terms of speed and resiliency. It feels much more reliable with updates etc.

Exactly, Seafile is the best I’ve found so far but a clean re write of the basic sync features would be great.

Seafile for example has full text search locked behind a paywall even though tools like Elasticsearch could be integrated into it for free. Even the android app as filename search locked behind a paywall. You have to log into the website on your phone if you need to search.

Pathetic state of affairs.

Kde has a disable sleep button in the power/battery icon menu which I use as a work around, still annoying and yet another quality of life issue that Just Works ™ on other platforms

https://getaurora.dev/

Has been working for me. The issues I’ve encountered so far are all minor flatpak issues (Firefox not allowed to sleep-lock so the laptop screen shuts off watching videos etc)

When I was starting out I almost went down the same pathway. In the end, docker secrets are mainly useful when the same key needs to be distributed around multiple nodes.

Storing the keys locally in an env file that is only accessible to the docker user is close enough to the same thing for home use and greatly simplifies your setup.

I would suggest using a folder for each stack that contains 1 docker compose file and one env file. The env file contains passwords, the rest of the env variables are defined in the docker compose itself. Exclude the env files from your git repo (if you use this for version control) so you never check in a secret to your git repo (in practice I have one folder for compose files that is on git and my env files are stored in a different folder not in git).

I do this all via portainer, it will setup the above folder structure for you. Each stack is a compose file that portainer pulls from my self hosted gitea (on another machine). Portainer creates an env file itself when you add the env variables from the gui.

If someone gets access to your system and is able to access the env file, they already have high level access and your system is compromised regardless of if you have the secrets encrypted via swarm or not.