apt/apt-get in nextcloud app shell

[Robert Thomspon]

Does anyone know how to gain access to the package manager (or, have the package manager released so you can install packages via apt?) in Nextcloud app shell? It seems like an major oversight on tc's part to release apps, allow you apt access but lock you out of the package manager.)

 

[shadofall]

Again truecharts does not build the nextcloud container. Any limitations on apt/apt-get (or the alpine equivalent for alpine based containers) comes from the upstream source. In this case nextcloud it's self.

And despite.my better judgement. apt-get should work fine from the normal nextcloud shell, I just tested it on my test box.. But thanks to a bug from ix the first time you connect even when you select the nextcloud pod it goes to the hpb (where apt-get won't work). You have to hit reconnect then again select the nextcloud pod. Not that I would ever recommend doing something as foolish as using apt-get inside of nextcloud or any non persistent container that's just going to get wipedout the next container download. Also the proper nextcloud pod includes nano if that's what your after.

Just don't go complaining if you break your install

 

[Robert Thomspon]

Again truecharts does not build the nextcloud container. Any limitations on apt/apt-get (or the alpine equivalent for alpine based containers) comes from the upstream source. In this case nextcloud it's self.

And despite.my better judgement. apt-get should work fine from the normal nextcloud shell, I just tested it on my test box.. But thanks to a bug from ix the first time you connect even when you select the nextcloud pod it goes to the hpb (where apt-get won't work). You have to hit reconnect then again select the nextcloud pod. Not that I would ever recommend doing something as foolish as using apt-get inside of nextcloud or any non persistent container that's just going to get wipedout the next container download. Also the proper nextcloud pod includes nano if that's what your after.

Just don't go complaining if you break your install

Apt-get would be to install nano.
Nano would be installed to edit a file (in this case, php-fpm.conf
Php-fpm.conf contains pretty important settings that even nextcloud claims is incorrect in your deployment.

And I don't complain when I break my install... If I break it, I either know how to fix it, or I'm willing to reinstall or at worst, start from scratch.

<Removed comment about hpb, I can't find strikethrough on my phone, so... Just removed it>

and, while I appreciate the insight, it's. It really helpful to constantly deflect everything as not being Truecharts fault. You guys have (from my point of view) attempted to deflect any and all blame. If it doesn't work, you blame TrueNAS... Or upstream. Seems like nothing is ever the fault of Truecharts...

 

[Robert Thomspon]

Again truecharts does not build the nextcloud container. Any limitations on apt/apt-get (or the alpine equivalent for alpine based containers) comes from the upstream source. In this case nextcloud it's self.

And despite.my better judgement. apt-get should work fine from the normal nextcloud shell, I just tested it on my test box.. But thanks to a bug from ix the first time you connect even when you select the nextcloud pod it goes to the hpb (where apt-get won't work). You have to hit reconnect then again select the nextcloud pod. Not that I would ever recommend doing something as foolish as using apt-get inside of nextcloud or any non persistent container that's just going to get wipedout the next container download. Also the proper nextcloud pod includes nano if that's what your after.

Just don't go complaining if you break your install

Oh man!!! You are a lifesaver!

How did you figure out that it was still connecting to hpb and needed just to 'reconnect'?

(For the record: that works perfectly!!!)

And, since I'm sure you'll see this, is there any way to get that added to the info blurb when setting up nextcloud app? (Seems like it's pretty important info to know :) ) not sure I ever would have realized that without you pointing it out. Just not something you really take into consideration that it's mounting the wrong thing ;)

Anyway, once again, that k you for the help!

 

[shadofall]

the wrong pod issue is a known IX Bug. has been for a while. it impacts all multipod apps not just nextcloud

and its not deflecting when its true. who ever builds the containers controls what is and isn't included. thats just docker 101, if the person building the container decides to remove apt/apt-get (or alpine equivalent) in their container. there's no way to restore it downstream. you have to build your own., personal opinion seems like a waste of resources to build a container your self when there is a perfectly viable container available

and in all my years I've never personally come across a docker style container where the upstream provides the SU/root password for the "OS aspect". for obvious security reasons, so no one would have that but the container builder. and i wouldnt be surprised if most times its just randomized.

now of course obviously if a container does not run as root, which truecharts only runs as root when it has to. when you shell in from IXs webui you wont be root. which of course will impact apt/apt-get Thats actually a k8s limitation. where as docker exec will allow you to shell in as a specified user IE root on docker setups,, kubectl will not (Security again i'm guessing) on kubernetes setups. AFAIK from looking in to it

 

[Robert Thomspon]

the wrong pod issue is a known IX Bug. has been for a while. it impacts all multipod apps not just nextcloud

and its not deflecting when its true. who ever builds the containers controls what is and isn't included. thats just docker 101, if the person building the container decides to remove apt/apt-get (or alpine equivalent) in their container. there's no way to restore it downstream. you have to build your own., personal opinion seems like a waste of resources to build a container your self when there is a perfectly viable container available

and in all my years I've never personally come across a docker style container where the upstream provides the SU/root password for the "OS aspect". for obvious security reasons, so no one would have that but the container builder. and i wouldnt be surprised if most times its just randomized.

now of course obviously if a container does not run as root, which truecharts only runs as root when it has to. when you shell in from IXs webui you wont be root. which of course will impact apt/apt-get Thats actually a k8s limitation. where as docker exec will allow you to shell in as a specified user IE root on docker setups,, kubectl will not (Security again i'm guessing) on kubernetes setups. AFAIK from looking in to it

Well, Im glad you stumbled across my question and shed some light on this for me. I honestly dont really reach out looking for help very much (and usually when i do, its for complicated stuff that pushes my knowledge)... So, i was unaware of the iX limitation on the pod mounting (The issue at hand).

And again, thank you for just that little blurb. I have a feeling its going to come in handy when i roll back to fighting Matrix/Synapse.

 

[stavros-k]

You guys have (from my point of view) attempted to deflect any and all blame.

Yes, we do so when it's NOT our fault. And pointing to the right direction to ask for help.

When it's our fault, we say it. And we fix it.

there's no way to restore it downstream.

While there are ways to do so, It's not best practice to either docker or kubernetes to do so.
(On containers that are not designed to have package managers)
For example hbp container, NC decided to have shell / apt access.
The "wrong" container you connected (due to the UI bug), creator decided to not have shell / apt access.