Having issues running a “cat” to pass cloud-init data to LXD’s lxc config command and getting the error:
Error: Can’t read from stdin: read /dev/stdin: permission denied
Started snapping a preliminary automation tool. Found that when testing everything outside of the snap I can accomplish the task a few different ways without issue. Can also run snap shell and execute all intended functions in that shell.
For troubleshooting & test purposes, I broke out the issue in question into a small standalone repo with instructions. README.md covers the gamut of what i’m experiencing.
As part of troubleshooting I tried running:
$ sudo snap connect lxd:lxd-support core:lxd-support
From this thread for ideas but did not change my results.
I have a larger project that requires this command be functional. Its part of an automated sosreport prep+analysis & statistic collection tool in a support environment. LXD comes into play for customer data isolation reasons following an existing process thats currently very manual.
When I came across this issue I broke out an exercise to isolate the problem & experiment with just this command.
As part of a larger whole its useful for automating & hooking into another tool we use to track cases & statistics.
The goal is two parts.
A) looking to improve tool delivery via “snap install” distribution across my team including this automation for isolated log prep, analysis, and statistics analysis for long term tracking/audits.
B) a learning exercise for getting comfortable with snap packaging on this and other more complex projects.
In your opinion, should the stdin permission error be expected?
Thank you for the extra context, it helps (lxcinit being an internal, developer tool means I shouldn’t worry too much about it not working outside of devmode, although I’d still suggest cleaning up the snap a little as it seems to use paths to /snap/<thesnap>/current instead of $SNAP, for example, which might be a problem if you rename the snap, or move it to classic confinement; it also has the lxcinit script twice, which can be confusing).
The problem as I understand it is that when you do
foo < bar
then the shell you are running opens bar and passes that file descriptor to the process foo. In this case foo will run confined, and attempting to use that file descriptor will fail because that file is somewhere foo is not allowed to look.
Instead, you could do
cat bar | foo
which will work, as what will be passed to foo will be something that is no longer associated with a path it cannot access.
Just in case, paging @jdstrand so he can confirm I’ve understood that properly =)
Agreed, there’s some clean up to do, this was a demo for specific command issues and the polish isnt there. Besides the fact I’ve been in the bash/python (or any scripting/programming) world just 3 months so far. Still super green. Thanks for the pointers.
I’ll jump back in to test the cat bar | foo approach more thoroughly.
I actually have a discarded test script HERE.
Lines 21 & 27-31 were the different command formats I tried including your suggested syntax, but I can focus in on that more specifically in a few hours and see if that doesn’t get me closer.
