- This topic has 28 replies, 7 voices, and was last updated Sep 8-11:57 pm by Anonymous.
-
Posts
-
Xecure
So now few doubts:
Why would Antix choose to remove those options, if they’re even suggested by upstream developer?Those changes seemed to have been made by the Debian team to improve compatibility with raspberry pi. I say this because the change comes directly from the raspberrypi_config.patch
@Xecure:
Based on your previous advise, I was choosing to always unmount /live/linux (/dev/loop0) after finishing clean booting the live system. As far as I have used it, seemingly I haven’t noticed any “explicit” harm or malfunction until now. But, skidoo’s advise… is he actually right? Am I actually breaking the live system without noticing at all?The things mounted in /live/ are related to the linux squash file system (from live linuxfs) and the persistence file systems (for live persistence), and you don’t need to be bothered about them. Its the (behind the scene) antiX magic.
I never said “it is ok to unmount”, but that you don’t be bothered (ignore their existence and let them do their magic).
Searching the live scripts in gitlab does give an idea that it used. And, on my system, it mounts to /live/linux (where linuxfs file is mounted), so I do think it IS important (but not sure if also as important when you load the system to RAM).
The slow USB mounting, I still cannot reproduce. Could you try antiX-19.4 with a different kernel? Maybe the 4.4 version has better compatibility with your hardware or the 4.19 fixed a problem present in older versions.
I will test again, this time on an older machine, which I should be able to borrow tomorrow, to see if I can reproduce it there.- This reply was modified 1 year, 7 months ago by Xecure.
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Anonymous
Thanks for your help. I apologize if I was being a bit annoying.
Still, a few previous doubts…
If there are no explicit default options set in udevil.conf, then how do udevil and/or fstab assign “default” permissions? Where do they get “defaults” from?Does the option order in udevil.conf or fstab matter? For example, any effect if I put first the UID/GID options, and at the end the fmask/dmask options?
Is it really possible to *properly* install a different kernel on an Antix totally live system, without any kind of persistence option or installation?
If by any chance answer was positive, how would I do that?
Though I have been planning to do, I still haven’t had chance to go get some new USB sticks, which I’d also use to test whether the slow mounting happens as well…Regarding the CD/DVD thing, I noticed that Antix forcibly puts the optical drive used to boot Antix CD/DVD in fstab to be mounted in /live/boot-dev, which is owned by root. Thus, default as it seems, the optical drive used to boot the disk can no longer be used as regular user.
Is this expected default behavior on Antix?Where do they get “defaults” from?
.
When udevil is not used as the mount handler (such a when a mount operation is performed via ROXfiler, IIRC)
and no matching mount options have been specified within fstab…
(also during manual mount operatons, from commandline, if no explicit mount options are specified)
…and no explicit mount options were specified via the bootline…
…ultimately, the fallback mount options are based on configured per-filesystem-type defaults baked into the kernel.from a quick websearch, this
https://unix.stackexchange.com/questions/386412/how-does-mount-determine-the-default-mounting-options-for-newly-attached-filesysXecure
If there are no explicit default options set in udevil.conf, then how do udevil and/or fstab assign “default” permissions? Where do they get “defaults” from?
if the fmask and dmask are not set, they will take the values of 0000 (meaning, complete permissions). That is why you have read, write and execute permissions for everything.
Is it really possible to *properly* install a different kernel on an Antix totally live system, without any kind of persistence option or installation?
If by any chance answer was positive, how would I do that?You require to remaster, so not possible in the same session unless you save the changes to the live media (which seems to be a CD, so impossible).
Regarding the CD/DVD thing, I noticed that Antix forcibly puts the optical drive used to boot Antix CD/DVD in fstab to be mounted in /live/boot-dev, which is owned by root. Thus, default as it seems, the optical drive used to boot the disk can no longer be used as regular user.
Is this expected default behavior on Antix?
This is the expected behavior if booting from a live CD/DVD, but should not be so for booting from USB. I think this was not mentioned in previous posts. Are you booting antiX from CD or from USB-drive? If the second, then the live system should not save cd -> /live/linux (as it isn’t its mount point) in fstab.
antiX Live system enthusiast.
General Live Boot Parameters for antiX./live/linux (/dev/loop0)
FYI, an excerpt from https://github.com/BitJam/Xlated-initrd/blob/master/live/README
(a local copy of this README file is present on antiXlive systems, but offhand I can’t recall its path)================= Live Mount Points ================= /live/aufs The union filesystem used for the main filesystem (same as /) /live/aufs-ram The RAM portion of the union filesystem /live/bios-dev Our best guess of where the legacy bootloader lives. Used for encryption and frugal installs /live/boot-dev The device the linuxfs lives on /live/frugal Used temporarily for frugal install. Becomes boot-dev /live/iso-dev The device the .iso file lives in for "fromiso" /live/iso-file Where the iso file is mounted for "fromiso" /live/linux Where linuxfs file is mounted for union filesystem /live/persist-root Where rootfs is mounted for static root persistence /live/to-ram Tmpfs for "toram" copy of linuxfs et alalso, regarding my earlier point “is a re-representation”…
Back around the time of antiX17 betesting, my suggestion to avoid duplicated results in “locate” command output was accepted
/etc/updatedb.conf ( find in file: prunepaths= )This is the expected behavior if booting from a live CD/DVD, but should not be so for booting from USB. I think this was not mentioned in previous posts. Are you booting antiX from CD or from USB-drive? If the second, then the live system should not save cd -> /live/linux (as it isn’t its mount point) in fstab.
Not mentioned here, but did in my very first thread/post: booting from CD, for now.
I still plan to go get some few USB sticks for testing…
(Too bad this laptop cannot boot from USB3 devices plugged to the USB3 port from UEFI/BIOS; one must plug the USB3 device to a pure USB2 port in order to be recognized by boot. Guess this rig lacks USB3 “drivers” in the firmware, or the like?)
What a weird default behavior for CD/DVD… What if I need to use Antix on an *older* PC with no USB boot function available, and need to work with more CDs/DVDs? I’d have to tweak stuff beforehand, instead of this working just out of the box…
By the way, gitlab link doesn’t work well for me, at least with Seamonkey nor Pale Moon. Page loads, but cannot see the actual commitment’s content: stuck in the “loading circle” gif…Also:
Does the option order in udevil.conf or fstab matter? For example, any effect if I put first the UID/GID options, and at the end the fmask/dmask options?Regarding the use of any admin stuff, this is something I have always doubted about all along… How should I actually use them best? If I have an opened terminal and did su/sudo there, or open an app as admin user (or want to browse the internal devices), and I have web browser, IRC or mail client, or anything else, up and running but as regular user of course, am I in danger as well?
Must I better close *everything* before attempting any admin stuff in the system?Thanks.
> Does the option order in udevil.conf matter
No. Rearranging the ordering has no effect.
ref: udevil.c#L779
However, bear in mind:
When udevil parses the conf file, it will balk (via stderr) if it encounters REDUNDANT lines which reference the same variable.For fstab, the line order does matter
ref: https://manpages.debian.org/testing/mount/fstab.5.en.html
as does the order of given options within each line (but in recent years, fstab and the mount command have become fairly “smart” ~~ able to apply the options correctly even if we specify them using incorecct field order).What a weird default behavior for CD/DVD… What if I need to use…
Probably necessary, at least during liveboot. During early boot when the mount occurs, the system (extracted from initrd) does not contain any record/knowledge regarding user accounts. Other distros may
automatically (transparently, unknown to the end-user) perform a subsequent remount during init.> plug the USB3 device to a pure USB2 port
^– Squinty tired eyes, I occasionally do that by mistake but even when using the “toram” option, the extra few (or 50) seconds at startup doesn’t raise my blood pressure. Same (no big deal) when I perform an occasional persist-save operation during the dynamic root persistence session while the pendrive is plugged into a USB2 port.
> gitlab link doesn’t work well for me, at least with Seamonkey nor Pale Moon.
Yep, peeps were discussing this same issue today in a different antixforum topic
forum software is refusing my attempted post.
test: Can I at least post an inline image here?
Regarding the use of any admin stuff… How should I actually use them best?
[..]
Must I better close *everything* before attempting any admin stuff in the system?Great (important) questions ~~ I’m tempted to suggest that they merit thorough discussion in a separate, dedicated, topic… but here I’m NOT suggesting a split.
For a new linux user, and for casual users (anyone who doesn’t care to bother reading docs, to gain understanding)
“using them best(root-permissioned commands, programs, terminal emulator shell)” primarily centers around “protecting you from tripping over yourself, for instance accidentally overwriting or deleting system-critical files“. If only programs from Debian repository and antiX//MX repository are present on your system, you will probably NEVER encounter “malware”, so any worry/attention toward the prospect of such is only a minimal consideration. Newer versions of Firefox browser will refuse to run as root; if concerned with the prospect of a browser exploit enabling badware to sniff/delete your (your user’s) $HOME directory contents, you can launch firefox into a restricted environment using the firejail utility.The as-shipped antiX intentionally omits several configuration amenities from the “root user’s” ~config directory.
When you launch a graphical program using the “gksu” command, the theming selected by your regular user is not applied to the window dressing.
This (discrepancy in theme applied) serves as visual cue, a reminder to “think twice, take care” before editing or deleting a system file.The image in the post above, shows is the “visual cue” I created to serve as a reminder for my kids when they are wearing clownshoes
(when they a running a program with elevated permissions)h t t p s: // pastebin.com/raw/24F3WpCg
^—- SAVE THIS TO FILE / root / .themes / garish /gtk-2.0 / gtkrc
THEN, AS ROOT, “gksu lxappearance” SELECT garish AS THE ACTIVE THEME———————————
SCUSA FOR THE INCOMPLETE REPLY IN THE PRIOR POST.
I HAD A HELL OF A TIME GETTING THAT PAST THE SPAMFILTER.pastebin.com/raw/24F3WpCg
Who would have guessed?
THE STUPIE FORUM SPAMFILTER IS APPARENTLY NOW REJECTING ANY POST CONTAINING A PASTEBIN LINK.
WHAT’S NEXT, USE OF VOWELS WILL BE FORBIDDEN ?!?Must I better close *everything* before attempting any admin stuff in the system?
No. Doing so would be non-useful and unnecessary.
advice specific to any terminal emulator program [urxvt, rox-filer, lxterminal, guake, et al]:
Avoid using elevated permission (via sudo or gksu) to launch a terminal emulator.
Launch as normal user & when necessary preface a command with sudo.,
Depending on which terminal emulator you use (and how it has been configured) you may (or might NOT) receive colored prompt text as a visual cue upon launching a “sudo bash” subshelladvice specific to spaceFM // zzzFM file manager:
From within an instance of the filemanager which has been launched as (by) your normal user, you can “File > Root Window”.
The newly opened instance will (unless disabled via prefs) bear a red-colored header to serve as a visual “think twice, take care” reminder.
.
Here, a separate, but related reminder: there is no Undo, no Trash, no RecycleBin
.
Because each instance of spaceFM // zzzFM can accept remote commands (sent from commandline or via unix sockets),
it is theoretically possible for a badware script to silently abuse/misuse the file manager’s functionality to perform dirtywork.
Across years, I have never seen such an exploit reported in-the-wild. Nonetheless, after using a root-permissioned file manager instance I immediately close it as soon as I’ve finished the task at hand. Later, upon reopening a new instance, all its tabs are remembered… and, in the meantime, one less window (taskbar icon) cluttering my visual space.———————————–
Later, when you are a seasoned user, as a convenience you might adopt the following practice:
( v—- typing here something that I wouldn’t mention in a separate, dedicated, BestPractices topic )
lxappearance, set a distinctively different (and gtk2+gtk3 capable) theme for root’s desktop theme.
Configure your window manager to initially start 2 (or more) workspaces.
optional: From WM autostart file, launch a script which applies distinct, custom, per-workspace wallpaper.
Upon each login, within workspace “A” launch a root-permissioned filemanager instance and terminal emulator instance.
then immediately change to workspace “B” and proceed to open web browser and whaterver day-to-day stuff(s).
Switch over to workspace “A” for any root -related work (some are long-running tasks); never perform AsRoot work via workspace “B”.The above, I personally sometimes use that setup. In my use [single user system], it has not proven to be dangerous / harmful.
Also, Ctrl+Alt+F6 (or other Fnumber) I will switch between virtual consoles to perform root-permissioned commandline operations, and (switching away from… a console still logged in as root), switch back to F7 graphical session to carry on with the day-to-day normal user activities.IRC
Given a terminal IRC client, launched as normal user, although someone might “social engineering” attempt coerce you paste sudo somethingsomething “codez”… AFAIK no remote commands sent to your client app can “magically escape” thereby talking to any (if any) root-permission programs or processes currently running on your system.
Thanks very much for all your advise, @skidoo.
- You must be logged in to reply to this topic.
