- This topic has 36 replies, 3 voices, and was last updated Jan 14-2:05 am by ctcx.
-
Posts
-
dolphin_oracle
I meant an example home.xtra and where to put it on the live-usb.
I set a home.xtra folder under /antiX, with a single file in it, and the file contained did not show up anywhere under /home.
- This reply was modified 4 months, 3 weeks ago by dolphin_oracle.
ctcx
Don’t do that; do what skidoo suggested in that post:
echo “/home/demo/.fluxbox/menu” >> /home/demo/xtralist.txt
echo “/home/demo/.icewm/menu” >> /home/demo/xtralist.txt
echo “/root/bash_history” >> /home/demo/xtralist.txt
[…]
(etc, etc, both system and home files, but *always* specifying absolute paths)The home.xtra thing is just an inner mechanism for the script; it’s not meant at all to be manually created by the user
The user is just supposed to create the normal “home” absolute paths with the files.@masinick:
Sir, if you’re around, am I really failing to explain myself?dolphin_oracle
ok I sort of understand
your home folder modifications are in xtra.tgz. if after xtra.tgz is extracted, /home exists, the move /home to /home.xtra, and then let the live system create the home folder as usual. then copy the files from /home.xtra to /home, whatever they are, and then remove /home.xtra.
does that sound right?
dolphin_oracle
ok I sort of understand
your home folder modifications are in xtra.tgz. if after xtra.tgz is extracted, /home exists, the move /home to /home.xtra, and then let the live system create the home folder as usual. then copy the files from /home.xtra to /home, whatever they are, and then remove /home.xtra.
does that sound right?
if that process is correct, something is still wrong. on my test live-usb, /home.xtra is never created after xtra.tgz is extracted.
I put these changes up on my gitlab. maybe somewhere is a typo or something, please take a look.
https://gitlab.com/dolphinoracle/live-initrd.gz/-/commit/754bf292467be48ac4726ebca0d291d7293f322a
I just tested again with a newly created live USB with live-usb-maker. Still no problems?
In /var/log/live/live-init.log, is there even a “blank line” after the line “Populating home directory”?
Did you also try not with the tgz, but with the “xtra” directory directly instead?
When booting into the live system, are your modified files there, or are they the ones from home defaults from /etc/skel ?
Maybe I made a mistake?
If so, could you or someone else also help, please?I did check that Gitlab branch page, and I cannot see any typos…
dolphin_oracle
ok works when there is just an xtra folder.
does not work when there is an xtra.tgz file instead.
Does this issue happen even when you don’t put *any* /home stuff inside xtra.tgz, but other such as /root/bash_history, or stuff like /usr, /etc, or others?
If the home.xtra is not being there, then there was never a “/home” inside the tgz to begin with, or perhaps the unpacking of the tgz is somehow failing…
For the tgz, this is how I tested: on AntiX itself:
–Create a plain text file -say, xtra.txt for example- containing something like this:
/home/demo/something.txt
/home/demo/.config/geany/geany_custom.conf
Remember: all absolute paths, and exact file names; tar does not support wildcards or other “weird” stuff
–Run:
tar -zcv –files-from xtra.txt -f xtra.tgz
–Check:
tar -ztf xtra.tgz
Should display all stuff, just all without the initial ‘/’ in their absolute paths
–Copy the tgz to the live USBThis is also exactly equivalent:
tar -zcvf xtra.tgz /home/demo/something.txt /home/demo/.config/geany/geany_custom.conf […]
But long and ugly to type all absolute pathsIn the live-init script, you could temporarily change the line
echo_live "$_Copy_home_xtra_file_s_"
for something simpler -and uglier- like
echo "_Copy_home_xtra_file_s_"
(Notice the absence of the ‘$’, so it doesn’t take it as a variable)
Then, after booting, checking /var/log/live/live-init.log to see if there any sign of that message (or even if just a blank line) *right* after the line “Populating home directory”I reiterate:
Does this issue happen even when you don’t put *any* /home stuff inside xtra.tgz, but other such as /root/bash_history, or stuff like /usr, /etc, or others?
Because, being a gzip compressed file, I’d expect either everything or nothing…dolphin_oracle
the xtra.tgz file definitely has items in it under /home. they are extracted, and /home then exists, but the move to home.xtra never happens, and I get the very issue you are trying to fix. I’m attaching the xtra.tgz file I used. its inside a zip file because the forum won’t accept a tgz file as an attachment.
also, the system doesn’t work at all when home persistence is in use. likely /home isn’t where your code assumes at that point, because the mv command fails. this shows up in the screen output and the live initrd log file.
- This reply was modified 4 months, 3 weeks ago by dolphin_oracle.
- This reply was modified 4 months, 3 weeks ago by dolphin_oracle.
dolphin_oracle
it does occur to us that the effect you are looking for can be achieved with the existing system by targeting /etc/skel rather than /home, which would work whatever user is created, not just the demo user.
So I think we will not include those fixes, but will include all the others.
@dolphin_oracle:
First, I owe you -and everyone- apologies. It turns that my proposal was certainly incomplete.
Actually I didn’t have the testing USB at hand, but also I was actually being stubborn. Again sorry for this.On the other hand, I went re-checking the whole copy_xtra() function in the init script, and this time I think I finally fixed it for good, and *also tested* everything:
copy_xtra() { local bdir=$1 xtra_dir=$1/xtra tarball=$1/xtra.tgz if [ -e $tarball ]; then msg 'Unpack xtra tarball' gunzip -c "$tarball" | tar x -C $NEW_ROOT/ # To avoid conflict when live-init script creates home directory. # Would be cooler if Busybox's tar supported the --transform option, # in which case the below line would be not necessary [ -d "$NEW_ROOT/home" ] && mv "$NEW_ROOT/home" "$NEW_ROOT/home.xtra" fi local live_xtra='/live/xtra' if [ -d "$live_xtra" -a ! -d "$xtra_dir" ]; then msg 'Copy xtra file(s) from %s' "$(fq "$live_xtra")" # Copy into the antiX/xtra dir if we can, # otherwise copy directly to the aufs from the initrd if remasterable; then mkdir -p "$xtra_dir" (cd "$live_xtra" && tar cf - *) | tar x -C "$xtra_dir" else xtra_dir="$live_xtra" fi fi [ -d "$xtra_dir" ] || return local list=$(ls $xtra_dir) [ -n "$list" ] || return if [ -e $tarball ]; then msg 'Found both xtra tarball and xtra directory; taking priority on xtra directory' [ -d "$NEW_ROOT/home.xtra" ] && rm -r "$NEW_ROOT/home.xtra" fi msg 'Copy xtra file(s) to: %s' "$(fq $list)" # Use tar because cp stumbles on some symlinks in target directory (cd "$xtra_dir" && tar cf - *) | tar x -C "$NEW_ROOT" [ -d "$NEW_ROOT/home" ] && mv "$NEW_ROOT/home" "$NEW_ROOT/home.xtra" # Create a symlink to the /antiX/xtra directory if it exists local r_dir="$NEW_ROOT/root" local x_dir="$DEFAULT_DIR/xtra" test -e $r_dir/xtra && return test -d $r_dir && test -d $x_dir && log_cmd ln -s $x_dir $r_dir/xtra }All of this made me realize there was also another potential conflict: when both tgz and directory existed. I also fixed that, though the xtra directory is the one having priority…
Also tested with “persist_root” boot option, and everything still worked well: the files in the xtra stuff were present.
And yes, you’re right regarding the /etc/skel argument, though I really wanted to cover every possible case; when a dev felt like also including the /home directory for some reason, so to not having any errors or problems.
Given this, do you think you could reconsider by chance?
Thanks very much, and sorry again.
iznit
echo “/root/bash_history” >> /home/demo/xtralist.txt
permissions nightmare? security vulnerability?
an example
liveboot, toram eject.
Not using persistence because overall want to emulate Tails Linux immutable system.
But want to preserve ((( selected hand-picked ))) changed non-executable files.
Cannot place copies of them in liveusb-storage directory because
1) toram eject is in effect, and
2) possibly the storage partition is fat32 and file permissions will not be preserved.During shutdown, if /home/demo/xtralist.txt exists
((( really /home/*/.config/xtralist.txt )))
Copies of the files at the named filepaths would be placed into a xtra.{username}.tgz and that archive would be placed in /boot-dev/antix/xtra/, to be extracted back into place during next boot.Across sessions, I might choose to preserve changes to only “places.sqlite” and other *.sqlite files ((( firefox bookmarks and history ))) plus an extremely short list of selected files, instead of full persistence.
Really, I am not asking to have live init handle this, am just imagining a use case. It would be more transparent to run a user script during session logout to handle the archive packing and another script called from the session startup file to handle the unpacking. Oh, but this assumes everyone logs into a graphical session.
p.s.
cctx, I’m not second-guessing you nor arguing, okay. Your long post here above mine was not visible when I started typing this- This reply was modified 4 months, 3 weeks ago by iznit. Reason: added p.s. comment
@iznit:
Yes, you’re totally right. For the *hideous* /root example, of course one should set appropriate permissions beforehand before putting into the xtra stuff.But maybe that was not a good example at all. Actually I wrote the post in a big hurry.
Even under the strict context of “development use”, more proper examples would have been perhaps /usr, /usr/lib, /etc, or any other less sensible stuff other than /home…dolphin_oracle
I’ll take a look at your new code, but this will still fail is home persistence is enabled.
[ -d "$NEW_ROOT/home" ] && mv "$NEW_ROOT/home" "$NEW_ROOT/home.xtra"I’m not convinced about /home manipulations. The xtra.tgz or xtra folder would also need to be crafted in such way as the demo user is accounted for in the file structure. /etc/skel does not have that limitation, and has the added benefit that it will work when additional users are created, something that must always be considered when dealing with home folder default setups.
On the other hand if its harmless I’m not necessarily opposed either.
Yes, you’re totally right: this will be disaster if home persistence is used (I have only used root persistence…)
Look, if you find all of these “xtra patches” too convoluted, then as you said better leave stuff as it is. I just wanted to try proposing some ideas to improve, but reality is I’m still a noob.
Though, I’m certainly far more positive regarding the other stuff posted in the OP, which I was able to test better.
Having said that, this is the best I could come with for the xtra thing for home, as perhaps a last humble attempt to “fix”.
At the very beginning of the copy_xtra() function in the init script:copy_xtra():
local home_exist [ -d "$NEW_ROOT/home" ] && home_exist=trueAnd replace all instances of:
[ -d "$NEW_ROOT/home" ]
with:
[ -d "$NEW_ROOT/home" -a ! "$home_exist" ]No further changes needed in the live-init script.
Would that be a bit better?
Thanks.(EDITED POST).
- This reply was modified 4 months, 2 weeks ago by ctcx.
By chance any follow up?
Also, this has been left completely unattended:
https://www.antixforum.com/forums/forum/administration/site-help/
And I think it’s important as well.
- You must be logged in to reply to this topic.
