no apt after update to release

[indivision]

I propose a middle ground:

Add a check box in the System > Advanced settings that allows turning apt on along with a disclaimer. Off by default.

[This way iX can add that setting to the Debug output and know up front if they are looking at a customized system. Which maybe limits support possibilities.]

 

[stavros-k]

I propose a middle ground:

Add a check box in the System > Advanced settings that allows turning apt on along with a disclaimer. Off by default.

[This way iX can add that setting to the Debug output and know up front if they are looking at a customized system. Which maybe limits support possibilities.]

On the other hand, someone who has a basic terminal knowledge can figure out how to enable it.
(It just missing the execute flag)
If not, probably it's best to not fiddle with the terminal :D

 

[FabrizioR8]

Rather than reviving a dead thread that has almost nothing to do with your question, how about following the one piece of advice in the thread that's relevant to your question and filing a ticket?

I admit, it was late and I was frustrated so I left a comment. Yes, had already planned on filing a bug after getting some sleep.

 

[indivision]

On the other hand, someone who has a basic terminal knowledge can figure out how to enable it.
(It just missing the execute flag)
If not, probably it's best to not fiddle with the terminal :D

That probably works to some degree. True.

But, then the issue is implied rather than explicit. For users with broad range of experience I think it's better to build messaging into the software.

After all, what is going to happen is that people will write up step-by-steps that simply add the flag change as the first step. Then, step-by-step level users will end up in the same place without knowing the pros/cons.

 

[stavros-k]

I think it's better to build messaging into the software.

You mean something like the last lines?

Code:

> ssh truenas                                                                               
Last login: Wed Jul 20 10:49:38 2022

        TrueNAS (c) 2009-2022, iXsystems, Inc.
        All rights reserved.
        TrueNAS code is released under the modified BSD license with some
        files copyrighted by (c) iXsystems, Inc.

        For more information, documentation, help or support, go here:
        http://truenas.com

Welcome to TrueNAS

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.

After all, what is going to happen is that people will write up step-by-steps that simply add the flag change as the first step. Then, step-by-step level users will end up in the same place without knowing the pros/cons.

The thing with this, (the step by step guides) is that once users start copy pasting guides found on internet, without knowing what it does.
I guarantee you, it will break systems. Yes, I know, noone should run scripts/commands that don't know what they do. But let's face it, most people will just follow the steps.

If they try to install an X package. it might have a dependency Y of version Z.
Scale might depend on Y but on only tested that it works on version A.
They will start get small bugs which might be even untraceable (easily).

Lets say a bug report is open, iX will see the flag on the debug report, that you have enabled apt.
They can simple deny even looking on your bug.

But that won't work with 3rd part catalogs for example. People will ask help because X app doesn't work. But noone will know that fubared it with apt.

Yes, I exaggerate. But you see my point.

Imho, it should be removed completely :P
For someone that knows few basic things, it won't be hard to add on his own.

But, remember it's an appliance. If someone want's complete control, can boot a debian/ubuntu/whatever and do exactly how he likes!

That's at least how I see it

 

[anodos]

You mean something like the last lines?

Code:

> ssh truenas                                                                           
Last login: Wed Jul 20 10:49:38 2022

        TrueNAS (c) 2009-2022, iXsystems, Inc.
        All rights reserved.
        TrueNAS code is released under the modified BSD license with some
        files copyrighted by (c) iXsystems, Inc.

        For more information, documentation, help or support, go here:
        http://truenas.com

Welcome to TrueNAS

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.

That message is updated in SCALE:

Code:

<snip>

Welcome to TrueNAS

Warning: the supported mechanisms for making configuration changes
are the TrueNAS WebUI, CLI, and API exclusively. ALL OTHERS ARE
NOT SUPPORTED AND WILL RESULT IN UNDEFINED BEHAVIOR AND MAY
RESULT IN SYSTEM FAILURE.

Which is a bit more direct and clearer IMHO.

The messaging on login via SSH was updated based on community feedback from Eric Loewe, Joe Greco, and several others.

You are of course free to do what you want with the TrueNAS, but we generally don't accept bug tickets unless the issue manifests on an unmodified install.

 

[indivision]

You mean something like the last lines?

Code:

> ssh truenas                                                                              
Last login: Wed Jul 20 10:49:38 2022

        TrueNAS (c) 2009-2022, iXsystems, Inc.
        All rights reserved.
        TrueNAS code is released under the modified BSD license with some
        files copyrighted by (c) iXsystems, Inc.

        For more information, documentation, help or support, go here:
        http://truenas.com

Welcome to TrueNAS

Warning: settings changed through the CLI are not written to
the configuration database and will be reset on reboot.

I was meaning a disclaimer for installing packages via apt, appearing specifically when you take steps toward doing that.

Both this message and the updated one in Scale sound like they are referring only to changing the server settings. Not adding new packages.

The thing with this, (the step by step guides) is that once users start copy pasting guides found on internet, without knowing what it does.
I guarantee you, it will break systems. Yes, I know, noone should run scripts/commands that don't know what they do. But let's face it, most people will just follow the steps.

If they try to install an X package. it might have a dependency Y of version Z.
Scale might depend on Y but on only tested that it works on version A.
They will start get small bugs which might be even untraceable (easily).

Lets say a bug report is open, iX will see the flag on the debug report, that you have enabled apt.
They can simple deny even looking on your bug.

But that won't work with 3rd part catalogs for example. People will ask help because X app doesn't work. But noone will know that fubared it with apt.

Yes, I exaggerate. But you see my point.

I agree with this. That is what will happen. But, if you have an explicit disclaimer attached to going down that path those users will have been informed clearly up front.

I feel that would be more effective user management than relying on a technical hurdle to communicate something.

That message is updated in SCALE:

Code:

<snip>

Welcome to TrueNAS

Warning: the supported mechanisms for making configuration changes
are the TrueNAS WebUI, CLI, and API exclusively. ALL OTHERS ARE
NOT SUPPORTED AND WILL RESULT IN UNDEFINED BEHAVIOR AND MAY
RESULT IN SYSTEM FAILURE.

So, this one says that changing things via CLI is supported. I don't see how this language would warn someone off of using apt specifically.

You are of course free to do what you want with the TrueNAS, but we generally don't accept bug tickets unless the issue manifests on an unmodified install.

This is understandable. I only propose baking this point into the software messaging, for the benefit of both types of users and iX support efforts.

 

[danb35]

So, this one says that changing things via CLI is supported

Via the TrueNAS CLI. Not the Linux shell.

 

[indivision]

Via the TrueNAS CLI. Not the Linux shell.

I think that is unclear. But, it's just my 10 cents. Doesn't affect me either way.

 

[anodos]

I think that is unclear. But, it's just my 10 cents. Doesn't affect me either way.

I think original wording I proposed was TrueNAS WebUI, TrueNAS CLI, TrueNAS API, but that was considered a little to repetitive / redundant.

If there is a package that you would like included in TrueNAS SCALE, you are more than welcome to file an enhancement request on jira with the package details and it will be given due consideration. We have done this in a variety of cases for tools (especially things that are relatively self-contained).

 

[Patrick M. Hausen]

If there is a package that you would like included in TrueNAS SCALE, you are more than welcome to file an enhancement request on jira with the package details and it will be given due consideration. We have done this in a variety of cases for tools (especially things that are relatively self-contained).

I can confirm that this works and the tickets are worked on. I got VMware tools into SCALE that way.

 

[indivision]

I think original wording I proposed was TrueNAS WebUI, TrueNAS CLI, TrueNAS API, but that was considered a little to repetitive / redundant.

Even then, I think the issue is that many people will think that clicking on a shell button in TrueNAS that opens a CLI is in fact the "TrueNAS CLI."

If there is a package that you would like included in TrueNAS SCALE, you are more than welcome to file an enhancement request on jira with the package details and it will be given due consideration. We have done this in a variety of cases for tools (especially things that are relatively self-contained).

Thank you. I don't really need anything personally. I just saw the issue being debated here and was thinking of a solution that would be good for all, imo.

 

[danb35]

Even then, I think the issue is that many people will think that clicking on a shell button in TrueNAS that opens a CLI is in fact the "TrueNAS CLI."

The best solution there is to get rid of that shell button. But nonetheless, your point makes sense.

 

[indivision]

The best solution there is to get rid of that shell button. But nonetheless, your point makes sense.

Hehe. That wouldn't stir any complaints. ;)

 

[danb35]

It's not actually a bad thing, handy for a quick command or two. But (unless the one in SCALE is different than the one in CORE) it's so limited that it's almost more trouble than it's worth.

 

[danb35]

Hmmm, my email has a reply from @jasonmicron about how SCALE doesn't have screen installed. Though I don't see that reply here for some reason, the answer is instead to use tmux.

 

[Davvo]

I Always tought that the Web Shell was TrueNAS' CLI.

 

[danb35]

It's a way of accessing the CLI, but not the CLI itself.

 

[Ericloewe]

Though I don't see that reply here

Mod note: The author deleted their post after coming to pretty much the same conclusion that tmux is packaged "from the factory".

 

[jasonmicron]

Mod note: The author deleted their post after coming to pretty much the same conclusion that tmux is packaged "from the factory".

Yep - after I posted it I had a thought to try tmux and it was there, so I deleted it.