Can Stevo/Dolp/Fehl/Chris help me understand this, plz?

[Belham]

I tried posting about this here (got no reply):

https://mxlinux.org/forum/viewtopic.php ... f50de8b04c


Following up, below are two pictures: they should be self-explanatory. Why is the firewall terminal feedback different? No other distro I test and use (which is a large range) does this.

To further the noodling in my brain (as an example) I chose a service: saned. Disabled it completely (in /etc/default/saned), then removed that file out of /etc/default/ and then removed every trace of sane I could find in the system (i.e. /usr/bin/ and etc). I rebooted, still, the thing exists and is loaded. I then both tried, from a root terminal, to "service stop saned" and also tried "apt-get --purge remove saned" (which, again, included a reboot), and according to terminal commands as both user & root, the damn thing is still loaded and running after the reboot. Huh?

Something's not right here. I use many other Debian/Ubuntu/OpenSUSE/Arch/and Puppy stuff (though none are my go to like MX is), and nowhere do I run into this sort of thing when I attempt to simply find out what services are enabled/disabled/running and not-running, and to control them as root.

Thus, I know you guys are super-busy, but could someone please explain to my obviously ladled-brain what is going on--it would be greatly appreciated. Is this all maybe just a result of some mashup that MX has had going on with systemd vs init vs upstart vs systemctl or what?? By the way, Systemctl commands from root terminal just gives alot of garbled responses back, conflicting with what other commands bring back (and even conflicting with itself depending on how you structure the "systemctl" command). This doesn't exist in any Debian distro I use, yet it is rampant in MX. Is not MX mostly Debian-based??

[Please know what is descibed above has occurred across 4 different machines testing now, all fresh MX-18 installs, 3 64-bit OS installs and one 32-bit MX-18 install (laptop)...4 different ISO downloads & shasum-checked]

Thanks

[asqwerth]

I think checks on status of ufw/gufw, will require sudo to get an accurate reading.

[fehlix]

Why is the firewall terminal feedback different?

If I understand your two posts correctly, your question boils down to the question why
some init.d service shown running when queries as root user but not as normal user.
In the case of ufw, the answer is that the ufw-status query delegates this to a iptables query by issuing this command:

Code: Select all

iptables -L ufw-user-input -n

Running this as normal user will give a Permission denied error message, which is not shown using "service ufw status".
run as normal user:

Code: Select all

iptables -L ufw-user-input -n
iptables v1.6.0: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

run as root-user

Code: Select all

sudo iptables -L ufw-user-input -n
Chain ufw-user-input (1 references)
target     prot opt source               destination         
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:40816
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:40818
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 6881:6889
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 6881:6889

[Belham]

Hi Fehlix,

Thanks for responding. But what you wrote is already a given. You're missing the point---ufw, saned, they were examples. Root (or sudo or su) has nothing to do with what I am describing, for if they were, then MX would not have included in the .bashrc in the /home/ directory the following:

Code: Select all

[ -z "${PATH##*/sbin*}" ] || PATH=$PATH:/sbin:/usr/sbin

PATH="$PATH:/usr/sbin" 

Also, you're missing the point of the example of "saned" (see the next example for an even clearer understanding).


For example, for anyone involved with Linux over past decades, this series of simple commands in MX-Linux while in a root terminal, is enough to pull one's hair out:




But, yet, if you check other systemctl commands, you get this in MX:




This hydra-headed madness (is MX-Linux SysVinit or is it sysmtemd, and if both, then do not cherry-pick from both what terminal commands are relevant and which are not). As the above example shows, a user/administrator can never be sure---as things currently stand--- what services are actually enabled/disabled/running and not-running. Dolphin and/or Stevo, can either of you answer this?? MX has so many scripts under the hood, stuff happening at boot up, I mean............(and please know I am saying this is good-hearted jestness, but there's also a seriousness behind it as, just mentioned, a user and/or administrator cannot be sure of what is actually enabled/disabled/running and not-running in MX-Linux).

What exactly, as a user or administrator, is one supposed to believe and what commands are to be ignored in the root terminal? If one command from "systemctl" is included in MX,, then at the least include them all, yes??

Looking forward to hearing from either of you.

[asqwerth]

As I understand it, the user chooses whether to boot MX using sysvinit or systemd. That's why systemd packages are in the system and I guess if you tried to call the systemctl command, it might try to churn up something because the systemctl package is there.

But if you aren't booted using systemd, would systemctl commands even give you correct output?

I'm not a techy person, so I'm trying to understand if it even makes sense for you to be running systemctl commands while in sysvinit (meaning systemd isn't controlling the services normally).

[fehlix]

But what you wrote is already a given. You're missing the point---ufw, saned, they were examples. Root (or sudo or su) has nothing to do with what I am describing ...

I have shown the reason why with the example of ufw it shows as as not enabled when querying service status as normal user but shows running when queried as root. As I thought this was one main question you had. If you saying you did know that already then I would not have understand your question regarding the example ufw. For other services their are probably similar explanations. Also note do not mix systemd with init service status, as you can boot either with systemd or with sysvinit.

[dolphin_oracle]

I tried posting about this here (got no reply):

https://mxlinux.org/forum/viewtopic.php ... f50de8b04c


Following up, below are two pictures: they should be self-explanatory. Why is the firewall terminal feedback different? No other distro I test and use (which is a large range) does this.

To further the noodling in my brain (as an example) I chose a service: saned. Disabled it completely (in /etc/default/saned), then removed that file out of /etc/default/ and then removed every trace of sane I could find in the system (i.e. /usr/bin/ and etc). I rebooted, still, the thing exists and is loaded. I then both tried, from a root terminal, to "service stop saned" and also tried "apt-get --purge remove saned" (which, again, included a reboot), and according to terminal commands as both user & root, the damn thing is still loaded and running after the reboot. Huh?

Something's not right here. I use many other Debian/Ubuntu/OpenSUSE/Arch/and Puppy stuff (though none are my go to like MX is), and nowhere do I run into this sort of thing when I attempt to simply find out what services are enabled/disabled/running and not-running, and to control them as root.

well for one, the apt-get command is incorrect. there is not saned package. its part of sane-utils. So to purge it off, you would use

Code: Select all

apt-get purge sane-utils

as to the service "stop" command, that will stop the dameon for the current session, but it will come back on reboot. to disable totally

Code: Select all

service saned disable

or remove as previously discussed.

Thus, I know you guys are super-busy, but could someone please explain to my obviously ladled-brain what is going on--it would be greatly appreciated. Is this all maybe just a result of some mashup that MX has had going on with systemd vs init vs upstart vs systemctl or what?? By the way, Systemctl commands from root terminal just gives alot of garbled responses back, conflicting with what other commands bring back (and even conflicting with itself depending on how you structure the "systemctl" command). This doesn't exist in any Debian distro I use, yet it is rampant in MX. Is not MX mostly Debian-based??

[Please know what is descibed above has occurred across 4 different machines testing now, all fresh MX-18 installs, 3 64-bit OS installs and one 32-bit MX-18 install (laptop)...4 different ISO downloads & shasum-checked]

Thanks

so systemd and sysVinit are both installed. the system defualts to sysVinit, mostly for compatibility with the antiX live system. honestly, the only reason systemd is included at all is for compatibility with the debian repositories, as they have many many packages that require systemd to be installed (or at least, systemd-shim, which is how we pull off having 2 init systems installed).

systemctl actually does require systemd to be running as init for its output to work. As to why it "works" at all even when systemd is not running, well, ask the systemd developers why they assume their system exists in a vacuum and is pretty much designed to only work their way. But I digress....

Most other debian distros use systemd by default (and not sysVinit), so that's why your systemctl commands work correctly in those distros. They will work correctly in MX if you boot with the systemd enabled (which is an option on the installed system).

As the above example shows, a user/administrator can never be sure---as things currently stand--- what services are actually enabled/disabled/running and not-running.

As to your other questions about why output is different as root vs. as user, debian systems assume any administrator has root privileges, either thru sudo or through logging into the root account directly (su). I'm not 100% clear why certain commands have different output, but there are many that do. blkid is another one that drives us nuts. Yes, other linux systems may be different in this regard. One of our devs uses gentoo and blkid output works differently under gentoo for example. It may be user group releated, or some configuration/policy option somewhere that we haven't messed with. All that should be debian defaults.

The path statement just means some of the commands are available to the user to run. but the user doesn't necessarily have the permissions for full output. confusing I know, but true. ifconfig is another example. you can get status, but you can't manipulate the connection without admin priveledges.

[Belham]

Thanks everyone & especially Dolphin---what you wrote finally made the lightbulb (i.e. as to why systemd is included, er, I mean 'tolerated' and the ifconfig example) go off in my head.

Also, I laughed and not in a good way, when you said "systemd and vacuum...". Why? I happen to know one of the systemd developers, and, well, with him, his pat rely always is "it's how we operate and don't ask different." It never fails to remind me of the proverbial "people don't know what you're missing and/or is wrong until we tell everyone what is missing and/or wrong.."


Ok, all, no more crazy questions regarding this stuff.

Thanks much again for helping this old Linux user become at peace with the terminal again.

[rasat]

Interesting thread..... to convince "Puppy World" (mentioned in another thread) required two cats and one dolphin icon avatars. :) Belham, welcome to MX Linux. It is great to have you on board with your LFS (Linux From Scratch) experience.