I would like to request classic confinement for theTDengine snap.
TDengine is an open-source big data platform designed and optimized for Internet of Things (IoT), Connected Vehicles, and Industrial IoT. Besides the 10x faster time-series database, it provides caching, stream computing, message queuing and other functionalities to reduce the complexity and costs of development and operations.
Please find the yaml file from
TDengine’s core is a performance-critical engine for time-series data storage. It need access classic filesystem to store TB level data even more with very fast write and query performance. And it allow user to manually edit /etc/taos/taos.conf to adjust parameters for better fit with system configurations like CPU cores, hard disk type, hard disk capabilities to squazze more performance. And use can edit multi-machines’s configuraiton to add end points to build a cluster.
Right now classic mode works great at my local computer. Please let me know your comments.
Are there specific road blocks you ran into with strict confinement? As far as system wide configuration, you can store that in the $SNAP_DATA or $SNAP_COMMON. You can even hard code the paths those expand to if you don’t want to look up the environment variables at runtime.
If your server is primarily accessed via network sockets, then I would have thought strict confinement would be a fairly good fit.
Classic confinement is only a last resort, to get it granted you need to explain exactly why stict confinement did not work for you in the first place.
Looking at your code (launchers, hooks and snapcraft.yaml) you could solve all file location problems with some added layouts (having the target dirs point to locations underneath the variables james gave above) and properly defined plugs.
Also note that Ubuntu Core which is used a lot in IoT, automotive, industrial and embedded computing will not allow you to install classic confined snaps.
Try adding some layouts to re-map /etc/taos, /var/lib/taos and /var/log/taos, then turn the snap to strict confinement and use snappy-debug to get suggestions for the required plugs.
If you run into probs, post the snappy-debug output of an app run here along with your questions.
I would be very happy if the strict mode can satisfy the following requirements for TDengine.
TDengine need read /etc/taos/taos.conf with some preset configuration values. a default /etc/taos/taos.conf should be installed by snap installation if not exist. If a previous version exists, installation should not overwrite it. I tried the strict mode. seems my install hook to create file does not work.
Users can manually edit config file to adjust the preset value to tune better performance. I tried the strict mode. seems editing /var/snap/tdengine/current/etc/taos/taos.conf to change data location does not work.
user can specify data location to different hard disk for better performance not only the disk /var/snap belong.
the client we call taos became tdengine.taos with snap format. that’s fine we can tell the user the difference. the client will record the command history in a file named .taos_history in the user’s home. Next time users can use up/down to find the previous command list. With strict mode, it does not work. I guess it should be doable with strict mode. Maybe I misused home plugs. Appreciate it if someone can tell me how to fix it.
the client need to write log to /var/log/taos. Now it reports permission denied. I guess it’s similar to 4, I don’t know how to write plug to do it correctly. And the log storage location should be able to move to other disks for performance reasons like 3.
I am not sure if snap connect command can be done by install hook or another way. it’s nice if it can be done automatically by snap install. Then I don’t need to tell the user to do it manually. However, it’s not unacceptable although it does hurt user experience.
Are there any compile options or command line arguments you can use to change the location it looks for configuration files and writes log files?
As I said previously, snapd makes the locations $SNAP_DATA and $SNAP_COMMON available for snaps to write system wide configuration data. In this case, they would expand to /var/snap/tdengine/current and /var/snap/tdengine/common if you need to hard code paths in your app.
As far as changing the location where data is stored, one option would be to suggest users bind mount the alternative location they want data stored in.
Currently TDengine just use “-c path” to pass the directory where taos.cfg is.There are many configurable items in the taos.cfg for the purpose tune performance according to different CPU cores, memory size and also many options for different debug level for troubleshooting. To support them via passing too many command line argument seems less maintainable. We need provide more flexibility to the user. And keep the user using intuitive way to do that as what they used to do with classic Linux.
If you can set the configuration file location via an argument, then you could presumably set it as part of the command line for the daemon in your snapcraft.yaml.
Alternatively, if the configuration file needs to exist prior to the daemon running, you could launch the daemon via a shell script that copies a default configuration from your snap’s read-only data in $SNAP to a writable location in $SNAP_DATA, then launch the daemon with that configuration file.
i’m struggling to make my snap work well with confine mode.
I have three executable app commands. First one is a simple daemon. Seems it works now. The last one is a simple command with network plug now it is workable. The second one is a client need write log to /var/logs directory but it failed to open log file as permission denied. and it need to write a file
at user’s home directory. It failed too although I specified home plug in its section of snapcraft.yaml. Could someone please help to point me what’s wrong?
The snapcraft.yaml is here: https://github.com/taosdata/TDengine/blob/feature/sangshuduo/snap/snap/snapcraft.yaml
declaration-snap-v2:plugs_installation:historyfile:personal-files
human review required due to ‘allow-installation’ constraint (bool)
declaration-snap-v2:plugs_installation:systemfiles:system-files
human review required due to ‘allow-installation’ constraint (bool)
Warnings
security-snap-v2:interface-reference:historyfile:personal-files
override not found for ‘plugs/historyfile’. Use of the personal-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the ‘store-requests’ category (https://forum.snapcraft.io/c/store-requests), or if you would prefer to keep this private, the ‘sensitive’ category.
security-snap-v2:interface-reference:systemfiles:system-files
override not found for ‘plugs/systemfiles’. Use of the system-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the ‘store-requests’ category (https://forum.snapcraft.io/c/store-requests), or if you would prefer to keep this private, the ‘sensitive’ category.
tdengine_2.0.2.0_amd64.snap: FAIL
As we discussed in recent two weeks, I believe I have explained why using system-files and personal-files make sense to this software. Please let me know what I should do. Thanks.
@shuduo thanks - we can use this existing forum discussion to continue the review process - can you please state what access is being requested for tdengine via personal-files and system-files and why this is required?
@alexmurray
TDengine is a big-data platform and its core is a time-series database. There are a taosd server(daemon) and a client app, taos as primary parts and a few utility apps as additional parts.
The daemon and the client app need read configuration items from /etc/taos. The daemon need read/write all the data to /var/lib/taos (configurable in /etc/taos/taos.cfg). The daemon and the client app need write all the log to /var/log/taos (configurable in /etc/taos/taos.cfg). Those access request a system-files interface.
And the client need read/write a file named .taos_history in the user’s home directory for record and reuse command sequence as many databases software shell interface provides. This access requests a personal-files interface.
I assume the requester is asking to make the snap actually writing to the directories on the host’s rootfs instead of those accessible in the snap runtime?
In this case the answer is probably “snaps are designed not to write files to the classic system directories, just like you normally won’t make a docker container write logs to the host’s /var/log”.
My 2 cents.
EDIT: Backup my reply at #9 just so it wont be wrongly marked as the thread’s solution:
well, i’m just trying to point out that there is no actual requirement at all to write to these, using a layout is enough and you do not even need to request any review since this is the standard way to make apps like this “just work” without needing manual reviews or any changes to the app in any way … the same goes for the personal-files request , $HOME by default points to $HOME/snap/<snapname>/current/ for all snaps by default. the app has full write access there … unless you need/want to read any existing hosts files for migration purposes, none of the requested interfaces is needed when the packaging is done right …
@ogra
OK, I rechecked my snapcraft.yaml and removed all system-files interface related lines. It does work well too as you described.
Now the client still failed to access $HOME/.taos_history after I removed the personal-files interface. I see the original mechanism is to get home directory by “getpwuid(getuid())->pw_dir”, I think it did not get $HOME/snap/ directory. May I know if you would suggest what function should be used here to make both classic and snap to read right location?
@Lin-Buo-Ren I do expect the snap can access other locations for data store requires to utilize faster disk or slower disk. Jamesh had suggested to allow users bind mount other locations in earlier reply. I plan to do it later. The first step is to publish the snap with all normal behavior works.
I made a mistake to reject the new revision then clicked manual review again. I don’t know how to make it “without needing manual reviews” as ogra pointed out. Please help to process it or let me know what I need to do.
