Allow abra edit
or similar to edit files within a container #213
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#213
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the problem to be solved
It is a multi-step process to edit files within containers, which either involves
abra cp
to pull the file and edit it locally before pushing it back (which involves having to fix the permissions), or installing an editor in the container and editing it there.Describe the solution you would like
abra edit
would pull the file locally to a temporary file, launch $VISUAL or similar to edit the file, and if the file was changed, would push the file back to the container and ensure the permissions match the original state.Nice one @cas! Could you not
abra app run foo.com app vi myfile.txt
? I guess the focus in this ticket is to get it back to your local for your own editor configs and such or? Can certainly see how this might be made more convenient.@decentral1se most containers don't include a text editor, so I guess we'd need
Given we need this for Nextcloud and Federated Wiki SSO set-up (hand-editing config files YAY!) it seems worth having a convenience command to me 🤔
Right yep. How we can teach
abra
to understand the differences with permissions and package managers tho? E.g. on a keycloak, you can't even run an update/install with the container user permissions. In order to do that you have runapp run --user root app mykeycloak app sh -c "microdnf update && microdnf install vim && vi myfile.txt"
🙈Another approach, we do some sort of sshfs local mount of the file for local editing? Don't really wanna take on an additional dependency for just this but it might be doable without. (EDIT: did see https://github.com/nxsre/sshfs-go tho)
I think the original suggestion was
abra app cp
/ local$VISUAL
/abra app cp
, to avoid that kind of mess.abra app edit-file foo.com app:/var/www/config/config.php
would be an alias forabra app cp foo.com app:/var/www/config/config.php /tmp/
$VISUAL /tmp/config.php
(maybe using the same "what if you don't have an editor set" menu asabra app config
?)abra app cp foo.com /tmp/config.php app:/var/www/config/
And for incredible bonus points, saving and restoring the file attributes to avoid needing to chmod after.
SSHFS would be great usability but it would mean needing an SSH per service which seems slightly nightmarish, or implementing #10 which I still have no good ideas on.
Ah riighhhttt, gotcha! 1. 2. 3. sounds v nice then, thanks for bringing me along 💙
I'll try to pick this one off shortly unless someone else wants to pick it up!
I can take care of that if you haven't yet!
Yes please 🙏
So far all abra data is stored in ~/.abra and i'd like to keep it that way. So I'd rather put the downloaded file in ~/.abra/.appname.filename or something simillar to avoid edge cases such as lack of /tmp directory or permission issues. What do you think about that?
I think this sounds great!
yeh nice! also
~/.abra/tmp
might be a thing if other stuff needs it but idk that will happen :)there is a permission problem. To reproduce:
deploy traefik
pull /entrypoint.sh:
abra app cp -d traefik_your_domain app:/entrypoint.sh .
so the file gets copied but loses its permissions and date of creation/access etc:
inside docker container:
local version:
Additionally the ACL's might also get lost if they exist. I don't have any image that supports them though.
possible solutions:
require root to pull filesjkstat -c "%u" "pulledfile"
(for UID) andstat -c "%a" "pulledfile"
(for access rights) on the file, save this information to ~/.abra/.filename.ownership and then run chmod and chown inside the docker container once it's there. Can do the same for dates and then usetouch
inside the image to change the dates.cat newfile > oldfile
(sounds dodgy)what do you think is best?
Ah yes, well spotted and explained, thank you 🙏
My favourite option is the
~/.abra/.filename.ownership
idea, I think.Some thoughts:
when the operation succeeds (the file is successfully pushed to the container), local version gets deleted and we're golden
BUT
when the operation fails (oopsie you tripped over your power cable while editing the file 👀)
~/.abra/.filename
is not a good place to put those files because it will leave orphaned files in there.~/.abra/tmp/edits
would be better. Ideally we create two files every time you edit a file:~/.abra/tmp/edits/appname/servicename/filename.file
~/.abra/tmp/edits/appname/servicename/filename.metadata
note that if the operation succeeds the whole
edits
directory gets removed (with an equivalent ofcd ~/.abra/tmp; rmdir -p edits/appname/servicename
) which means that if it exists, a previous operation was interruptedfilename.file
contains the contents of the file andfilename.metadata
contains the following info:if err != nil { logrus.Fatal(err)}
of course)this approach makes it an atomic operation i think? as even when it's interrupted because of a failure it will be in a known state.
and then add
--continue
(default) and--redownload
(maybe phrase it better) flags controlling the resolution of situation where the file already exists. Any improvement points?Wowza yeh, sick analysis! I'd be inclined to say that if such a convenience command requires such an inconvenient implementation (which will most likely result in bugs because yanno) then it is worth reconsidering if we wanna do this? Seems like getting into potential cases of data-loss would be no-bueno...
there is no added data loss cases - after all you'll still interrupt the manual process by unplugging your pc halfway trough editing a file. The question is: how many hours do we want to throw at it?
This will require more work than expected because of how docker SDK for Go works. https://stackoverflow.com/questions/52774830/docker-exec-command-from-golang-api this is needed for preserving the correct access rights of file (running
stat
in the container). We'll take a look at this after beta release!