Hosting a community (discussion forum) for docker-scripts

On another topic I have posted some instructions about upgrading a nextcloud installation to use the new version of docker-scripts.
It is actually copied from this post:
https://talk.fs.al/-23/how-to-upgrade-nextcloud-to-the-new-scripts

In general, I realize that it is useful to have a community (or discussion forum) for the users of docker-scripts, in order to post any news, to answer any questions, to report any bugs or issues, etc. Several times in the past I have introduced some breaking modifications to the scripts, without proper notifications to the users, and without clear instruction on how to upgrade. This is not good and may create any difficulties for the users, which have to find out themselves how to do it. Such a community may help to avoid or minimize such problems.

For the time being I have created this forum: https://talk.fs.al/latest/docker-scripts, which is based on TalkYard. However I am not quite happy with it. TY is great for embedded comments, but it is not the best one as a forum (in my opinion). For example Discourse is much better as a discussion forum.

:backhand_index_pointing_right: Another option is to use my own Discourse forum at https://fol.fs.al, but this mainly an Albanian forum, and mainly non-technical, so docker-scripts discussions don’t fit very well on it.

:backhand_index_pointing_right: Another option is to install another Discourse instance (on my server) just for docker-scripts discussions, but this seems like an overkill right now, since there are not so many users of docker-scripts and not enough discussions (yet).

:backhand_index_pointing_right: Yet another option might be to create a public group and public category for docker-scripts on the LUGBZ discourse (this instance).

How is docker-scripts related to LUGBZ?
Well, for those who don’t already know, the applications that are installed on the LUGBZ server (Postfix, WordPress, NextCloud, Discourse, Mastodon, etc.) are based on docker-scripts. So LUGBZ is one of the users of docker-scripts (besides me, because I am using them on my own server).
[I am not sure if everyone is happy and satisfied with this, but this is how it is up to now (as far as I know).]
So, maybe it makes sense to host the docker-scripts community on this forum, as a separate discussion category. Later, if we decide for some reason to move it somewhere else, it is easy to export all the topics and discussions of a certain category, and to import them to another Discourse instance.

So, I have this request (that should be discussed and decided by the board, or the members, or whatever is appropriate according to the status of LUGBZ):

Can we create a separate group and discussion category for docker-scripts, where I am one of the moderators?

  • Agree
  • Disagree
  • Neutral
0 voters

thankyou dashamir !

my biggest motivation to be active within LUGBZ is: promoting KNOWLEDGE-SHARING for a common understanding between good-will-people.

(i.m.h.o.): your proposal fits perfectly into this perspective !

grazie dashamir!

la mia più grande motivazione per attivarmi nel LUGBZ e’ la voglia di promuovere la CONDIVISIONE DELLA CONOSCENZA per favorire la collaborazione tra persone di buona volontà.

(i.m.h.o.): la tua proposta si inserisce perfettamente in questa prospettiva!

toni

1 Like

Sorry Dashamir for my late reaction. You published the topic shortly before my trip and afterwards it was lost in the flood of messages.
The dockerscripts were not directly announced in the course, but we course participants used them, otherwise the topics would not have been covered in time. As for me, I can say that I have not looked into them further, but I realize that in order to understand the context correctly or even to use them as a pattern for apps that have not been covered, I still have a lot of work ahead of me.
Therefore, I would be really happy if a discussion on this could arise here on talk.

PS: the links in the post are no longer correct.

Danke @toni_member , dass du mich dran erinnert hast.

I shall never be interested in knowing more about docker scripts, but I totally support The proposal by Dashamir.
IMHO “this” forum is for all kinds of dicussions, including technical ones, as well as organising Biergarten meetings :clinking_beer_mugs:
Please apologise if I will not participate in either kinds of interactions, too far away, and feel free to toast to my health, I shall do the same at my home :beer_mug:

Buona serata
gabriella

Actually they were announced. The Part 3 and Part 4 of the course description were all about docker-scripts: cloud-apps.md - Nextcloud

The aim of this category/community would be to facilitate discussions about docker-scripts, including questions or asking for help if something does not work as expected.

Thank you for the support. We can’t expect everyone to be interested in everything. With Discourse it is possible to unsubscribe from a discussion category (the bell icon at the top-right) and it will never notify you about the discussions of that category.

Yes, you’re right. I didn’t understand Docker-scripts as your work, a kind of framework that uses shell scripts to create a unified CLI for common tasks of cloud apps, which internally solves tasks very differently depending on the app.

For me, docker scripts were scripts like the thousands that can be found under this keyword, which solve a task and which, ideally, can be reused, but usually have to be adapted to your own requirements.

1 Like

This is a good description for docker-scripts.

docker-scripts try to make easy self-hosting of web-apps and web-services on a cloud server. It is mostly useful for personal/family usage or small organizations.

Some alternatives might be: YunoHost, FreedomBox, TurnKeyLinux, NethServer, etc. (please add the ones that I have missed).

It has technical differences with these alternatives, as well as advantages and disadvantages. The main difference is that all the other alternatives promise an easy management of the apps with just a few clicks (from a web GUI), while docker-scripts promises an easy management with just a few commands. The other alternatives try to isolate the user from Linux and from the command-line, while docker-scripts tries to encourage using the commands and bash scripting.

One of the advantages of the alternatives is that they have nice websites, big communities, and they support more applications then docker-scripts.

The main advantage of docker-scripts comes from the fact that the users can leverage the power of Linux commands and bash scripting to adapt and better integrate with each-other the applications that they install.

I’m very happy with the Docker scripts; I have no problem with the CLI. The problem is more that cloud apps are so diverse and setting them up is anything but trivial. The Docker scripts and GUI solutions hide a lot of complexity, but this complexity is necessary to run cloud apps securely on the internet. From this perspective, I am a script kiddie who wants to know what is behind it all, which is unusual.

Perhaps it will be clearer if I explain my motivation for taking the course. Last year, I replaced my old home server and various Raspberry Pi devices with a Proxmox system and had to learn a lot in the process. With the course, I first wanted to get to know Docker better, as well as incus, the alternatives to Linux containers and virtual machines offered by Proxmox. I had already used a VPS in the past to run a few tests or to bypass geoblocking. I only turned it on for that purpose. I can access the local server with VPN, which is becoming less and less necessary.

Now I realize that the cloud apps I already knew need to be much better secured on the internet, which requires additional programs. I can easily achieve this security with the Docker scripts as long as they work. At the latest when troubleshooting, I realize how much I don’t know.
With the Docker scripts, I have the opportunity to acquire the knowledge with considerable effort. I don’t know if I can still get through it at my age.

Regardless, I am excited about incus and the SNi proxy. An other proxy variant that I could use would be squid with access control.

1 Like

I have tried to build a squid container, long time ago, but I didn’t have to use it and it is a bit outdated (still based on bionic): docker-scripts / squid · GitLab

It was meant to be used as a transparent proxy in a gateway machine.

Maybe some day I will update it (or maybe you can give it a try, just for fun).