I love the Proxmox community scripts but Incus is my deployment method of choice, so I wrote a tool called surgeon to make surgical modifications of an upstream repository in a fork.
If you’re unfamiliar, the Proxmox community scripts give you a suite of over 200 scripts that create lxc containers or vms on Proxmox.
It’s still early, but almost all of the “CONTAINER” scripts are working. So if you wanted to install a Ghost blog instance on your incus server, you could visit this url and copy the script to launch an instance.
Currently container instances are supported and VMs are not.
If this is your cup of tea, I’d love to have more eyes on it, both for testing and for contributions. With the coming Fangtooth release, this could be a great resource for the TN community.
I dont think this will work. These scripts basically control LXC to make instances. But on Truenas all changes not made in UI will be lost. So anything made with these scripts will be unstable at best and realistically lost on upgrade.
You’re saying any incus containers that aren’t created in the UI won’t survive an upgrade? That’s not how incus works, TN would have to be actively deleting them.
Kinda. Incus stores its config in /var/lib/incus/ Every Truenas upgrade start from clean install and then applies changes according to Truenas config. So if you have something custom that is not in Truenas config, it disappears. (Correct me if I am wrong)
I guess the container volume itself would survive. But what good is the volume if all config for it is missing.
I manually started an incus container from the cli. then I applied a pending update to the TN host, rebooted, and the incus instance still exists. I don’t think this is an issue.
You are right. I just tested it with simple custom created container. After upgrade the container even with custom config is still there.
I was somehow very confused about the location of data originally in /var/lib/incus/. Well, I still kinda am.
But I am glad this works. This means custom changes should be possible. Thanks for pointing this out.
Major updates over the past week. The website is now live and updated, and most of the blockers for basic and some advanced usage are fixed.
I modified all the areas of the process that might assume a regular linux filesystem to make it easier to use on TrueNAS.
I removed all the sketchy-looking scripts, and ones that don’t apply to Incus.
And I got rid of the curl|bash in favor of a cli. This allows me to completely skip modifying upstream’s build scripts, since they’re not used at all now.
Give it a try and let me know what you think. If you choose “Advanced” installation, any of the container scripts can be used to create an Incus VM now too!
I’ve made a few changes to make IncusScripts more friendly to TrueNAS.
To install, create a new dataset somewhere, then download the latest release and move the binary into your dataset. Run it as root, or add the truenas_admin user to the incus-admin group.
You can see all the available scripts on the website
It’s still rough in a few places, notably you can’t bind any volumes from the host. Give it a shot and let me know what you think. Issues on GitHub are even better.
I run over 30 of that scripts at my Proxmox, so as soon as I update my TrueNAS instance I will try to provide you feedback and move some of them between systems. Thanks for this!
I created a custom Macvlan via the command line when using a Docker container, and apparently this configuration was not recorded by the TrueNAS database. When I reinstalled the TrueNAS system without saving the configuration file and re-set the Docker-bound Pool, this Macvlan reappeared. This means that some configuration data of TrueNAS is not saved by the database.
That’s correct. There’s a difference between shell changes and ones initiated by the API / UI. We are currently making no special effort to store these configuration changes on update. This is the way things always have been for TrueNAS. See the SSH login banner:
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.
Granted that’s giving extreme cases of negligent changes, but consider it constructive notice that once you make changes on your own you’re going to maintain them on your own
If you need a particular feature feel free to make a feature request, then steps can be made to properly implement and test it.
Thank you very much for your work. The tragedy of TrueCharts shows that TrueNAS does not seem to consider the compatibility of third-party tools and has made many adjustments to the technology stack in history, which means that IncusScripts may be completely unavailable after a system update. Perhaps you can try to seek cooperation from TrueNAS officials, which can avoid many subsequent problems.
The existence of the TrueNAS configuration database and the use of Squashfs make configuration changes very complicated.
Some configurations are obtained by TrueNAS from the system in real time. For example, if I change the name of the dataset through the shell, TrueNAS can read the new name normally after refreshing.
Some configurations are written to the configuration database by TrueNAS and cannot be updated except through the WebUI. For example, if I change the name of the zpool through the shell, TrueNAS will only read the old name stored in the configuration database, resulting in an error that cannot be fixed even after restarting unless some magic methods are used (exporting zpool in the WebUI and re-importing it).
Some configurations do not provide an entry for modification through the WebUI. After modification through the shell, it will be reset after the next restart of TrueNAS.
Some configurations do not provide an entry for modification through the WebUI. After modification through the shell, it will NOT be reset at the next restart, but it will be reset at the next system upgrade.
Some configurations are stored in Docker Pool or other pools. These configurations may or may not be reset after the system is restarted or upgraded. They may even conflict with the default configuration after an upgrade.
I believe this will confuse many people because not every user understands this configuration mechanism.
Some configurations are obtained by TrueNAS from the system in real time. For example, if I change the name of the dataset through the shell, TrueNAS can read the new name normally after refreshing.
Not as simple as that. There are various configuration points that use filesystem paths (shares, cloudsync, etc) that are not updated when you rename a dataset from shell. This will lead to breaking any service that has a path defined within the dataset.
I believe this will confuse many people because not every user understands this configuration mechanism.
There’s no need for them to understand the backend implementation. As noted in the warnings and in our documentation, the only supported way to make system changes is through our UI / API. The CLI mentioned is not a traditional unix shell, it’s the CLI utility that wraps around our API.
