On 15.01.2026 03:14 rbowman rbowman wrote:
ifconfig works fine for me and I don't have to read the whole damn ip
man page to coax the info out of it.
Some distributions do not ship it by default, but moved it to a
separate package.
Marco Moock <mm@dorfdsl.de> wrote:
On 15.01.2026 03:14 rbowman rbowman wrote:
ifconfig works fine for me and I don't have to read the whole damn ip
man page to coax the info out of it.
Some distributions do not ship it by default, but moved it to a
separate package.
Some Linux distributions still ship with ifconfig and without ip.
Plus ifconfig is common between different UNIX-type OSs. It looks
like there's still no ip command in the BSDs, for example.
On 16.01.2026 07:53 Computer Nerd Kev wrote:
Some Linux distributions still ship with ifconfig and without ip.
Which one?
Plus ifconfig is common between different UNIX-type OSs.
The command name is, but the options are different.
AIX and FreeBSD have -d, Linux doesn't, just for example.
Various other differences exist, just compare the options listed in the manpages.
not@telling.you.invalid (Computer Nerd Kev) wrote:
Marco Moock <mm@dorfdsl.de> wrote:
On 15.01.2026 03:14 rbowman rbowman wrote:
ifconfig works fine for me and I don't have to read the whole damn ip
man page to coax the info out of it.
Some distributions do not ship it by default, but moved it to a
separate package.
Some Linux distributions still ship with ifconfig and without ip.
Which one?
Plus ifconfig is common between different UNIX-type OSs. It looks
like there's still no ip command in the BSDs, for example.
ifconfig is common, but its parameters are different everywhere and
its output as well.
Just having the same command name doesn't constitute an acceptable
interface.
On Fri, 16 Jan 2026 22:28:07 +0100, Carlos E.R. wrote:
All that slower than simply calling again ifconfig.
I don't even have ifconfig installed!
On 2026-01-16 15:57, The Natural Philosopher wrote:
On 16/01/2026 12:48, Carlos E.R. wrote:
scp -- wrong. rsync, scp and sftp are all different ways of
transferring files securely over SSH.
Are they? even if you run rsyncd?
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption.
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2026-01-16 15:57, The Natural Philosopher wrote:
On 16/01/2026 12:48, Carlos E.R. wrote:
scp -- wrong. rsync, scp and sftp are all different ways of
transferring files securely over SSH.
Are they? even if you run rsyncd?
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption.
If you use "rsync://" on the client command line, you're connecting
to rsyncd using the Rsync protocol which doesn't use encryption,
which I often do for LAN transfers. You could still use SSH
tunneling for encryption of course.
On 2026-01-17 01:52, Computer Nerd Kev wrote:
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2026-01-16 15:57, The Natural Philosopher wrote:
On 16/01/2026 12:48, Carlos E.R. wrote:
scp -- wrong. rsync, scp and sftp are all different ways of
transferring files securely over SSH.
Are they? even if you run rsyncd?
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption.
If you use "rsync://" on the client command line, you're connecting
to rsyncd using the Rsync protocol which doesn't use encryption,
which I often do for LAN transfers. You could still use SSH
tunneling for encryption of course.
I am using the rsync:// syntax, and I don't remember opening another
port than 22. :-?
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
ifconfig is common, but its parameters are different everywhere and
its output as well.
Like most common UNIX commands are between different UNIX-type OSs.
Just having the same command name doesn't constitute an acceptable
interface.
They work similarly and give you a start with what to look for.
I've being playing with a 1990s UNIX-type OS lately and the
ifconfig differences weren't a problem at all. Plus I at least
know the command name so I can check the man page and see the
differences, without starting from basics and needing to learn
a completely different set of command names. Surely the advantage
is obvious?
Marco Moock <mm@dorfdsl.de> wrote:
On 16.01.2026 07:53 Computer Nerd Kev wrote:
Some Linux distributions still ship with ifconfig and without ip.
Which one?
Tiny Core Linux.
Plus ifconfig is common between different UNIX-type OSs.
The command name is, but the options are different.
Yeah, of course, but it's for the same purpose of "configure a
network interface".
AIX and FreeBSD have -d, Linux doesn't, just for example.
Ahh, "ifconfig --help" (GNU Inetutils) gives me:
" -d, -p, --dstaddr=ADDR, --peer=ADDR
set destination (peer) address to ADDR"
But it seems it doesn't match FreeBSD's "-d":
"-d Display only the interfaces that are down." https://man.freebsd.org/cgi/man.cgi?query=ifconfig
Various other differences exist, just compare the options listed in the
manpages.
Yes, but they're similar in purpose and general behaviour. Such is
to be expected between OSs. It's a really dumb argument for
omitting it entirely. Better change the "cp" command too in that
case because on BSD you don't get the "-b", "-u", etc. options like
in GNU Coreutils "cp" that's typical on Linux, so that's different
too, and so on...
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2026-01-17 01:52, Computer Nerd Kev wrote:
Carlos E.R. <robin_listas@es.invalid> wrote:
On 2026-01-16 15:57, The Natural Philosopher wrote:
On 16/01/2026 12:48, Carlos E.R. wrote:
scp -- wrong. rsync, scp and sftp are all different ways of
transferring files securely over SSH.
Are they? even if you run rsyncd?
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption.
If you use "rsync://" on the client command line, you're connecting
to rsyncd using the Rsync protocol which doesn't use encryption,
which I often do for LAN transfers. You could still use SSH
tunneling for encryption of course.
I am using the rsync:// syntax, and I don't remember opening another
port than 22. :-?
According to the man page it's TCP port 873.
Anyway I think it makes much more sense than dealing with all the complexities, fragilities, and inefficiencies of encryption just
to do transfers over a private LAN. LDO evidently concludes the
opposite.
Here's an example of a public rsync 'site'. This command lists
syncable directories and their descriptions:
rsync rsync://mirrors.dotsrc.org
This page also describes how it can use TLS encryption using a
script for OpenSSL "s_client", but that's not part of the base
protocol:
https://dotsrc.org/mirrors/#rsync-over-tls
not@telling.you.invalid (Computer Nerd Kev) wrote:
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
ifconfig is common, but its parameters are different everywhere and
its output as well.
Like most common UNIX commands are between different UNIX-type OSs.
Just having the same command name doesn't constitute an acceptable
interface.
They work similarly and give you a start with what to look for.
I've being playing with a 1990s UNIX-type OS lately and the
ifconfig differences weren't a problem at all. Plus I at least
know the command name so I can check the man page and see the
differences, without starting from basics and needing to learn
a completely different set of command names. Surely the advantage
is obvious?
So you would be fine with an ifconfig alias that maps to ip addr?
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
not@telling.you.invalid (Computer Nerd Kev) wrote:
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
ifconfig is common, but its parameters are different everywhere and
its output as well.
Like most common UNIX commands are between different UNIX-type OSs.
Just having the same command name doesn't constitute an acceptable
interface.
They work similarly and give you a start with what to look for.
I've being playing with a 1990s UNIX-type OS lately and the
ifconfig differences weren't a problem at all. Plus I at least
know the command name so I can check the man page and see the
differences, without starting from basics and needing to learn
a completely different set of command names. Surely the advantage
is obvious?
So you would be fine with an ifconfig alias that maps to ip addr?
That would still make the documentation hard to find (if you don't
know to check if it's an alias anyway).
I discovered ifconfig was depreciated when I asked Google Gemini how I could get it back... Anyway, I prefer the ip command - few less characters to
type.
Characters to type:ip l
ifconfig
ip link show
Pancho <Pancho.Jones@protonmail.com> wrote:
On 1/21/26 04:16, The Natural Philosopher wrote:
On 21/01/2026 00:32, Pancho wrote:
My concern was about having a root account.
AIUI, modern security advice is to not have an interactive root
account, i.e. with a password. So being a good boy, I don't. Whether
this strategy is practical in the real world is unclear to me.
I always enable one.
Sometimes when there is an emergency you need not to have to type 'sudo' >>> to edit every file...
sudo bash
sudo -i
And that's a bad idea.
If you delay an emergency solution significantly by five keystrokes
per action that you're too slow a typist anyway.
At least in openSUSE. No /home, no login, it silently fails (at least in graphical mode).
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
At least in openSUSE. No /home, no login, it silently fails (at least in
graphical mode).
Graphical mode. That could be your problem. But that's fixable with a
a little care for your X11 config. With no xsession or xinit files, it
should spin up a single xterm, maybe with twm. Wayland probably hasn't
got a fallback.
Elijah
------
not sure what mgr would do
On 2026-01-23 22:18, Eli the Bearded wrote:
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
At least in openSUSE. No /home, no login, it silently fails (at least in >>> graphical mode).
Graphical mode. That could be your problem. But that's fixable with a
a little care for your X11 config. With no xsession or xinit files, it
should spin up a single xterm, maybe with twm. Wayland probably hasn't
got a fallback.
If you can not login, you can not fix anything.
I don't remember the details, it was years ago. The point is that I
want every possibility available, in case something goes wrong. I want
to be able to login as root graphically, just in case.
I just tried in a fresh install of 16.0, and I can login as root into
XFCE. Yellow background. Perfect. Not even a warning message. Not that
I will use it, but I like that the decision is mine to take.
What's still puzzling me here is that passwd and shadow are under /etc,It depends on the setting of DEFAULT_HOME in /etc/login.defs. If it is
so... login should work regardless of /home being mounted or not?
On 2026-01-23 22:18, Eli the Bearded wrote:
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
At least in openSUSE. No /home, no login, it silently fails (at least in >>> graphical mode).
Graphical mode. That could be your problem. But that's fixable with a
a little care for your X11 config. With no xsession or xinit files, it
should spin up a single xterm, maybe with twm. Wayland probably hasn't
got a fallback.
If you can not login, you can not fix anything.
I don't remember the details, it was years ago. The point is that I want every possibility available, in case something goes wrong. I want to be
able to login as root graphically, just in case.
I just tried in a fresh install of 16.0, and I can login as root into
XFCE. Yellow background. Perfect. Not even a warning message. Not that I will use it, but I like that the decision is mine to take.
Elijah
------
not sure what mgr would do
On 2026-01-23 6:33 p.m., Nuno Silva wrote:
It depends on the setting of DEFAULT_HOME in /etc/login.defs. If it is
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
set to "no" the login attempt will fail in the absence of their home directory. If set to "yes", the login attempt will succeed and the user
will land in / instead of $HOME.
So the behaviour can be controlled by the system administrator.
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
On 2026-01-23, Carlos E.R. wrote:
On 2026-01-23 22:18, Eli the Bearded wrote:
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
At least in openSUSE. No /home, no login, it silently fails (at least in >>>> graphical mode).
Graphical mode. That could be your problem. But that's fixable with a
a little care for your X11 config. With no xsession or xinit files, it
should spin up a single xterm, maybe with twm. Wayland probably hasn't
got a fallback.
If you can not login, you can not fix anything.
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Perhaps unless this is going through PAM and there is some module doing something more than logging in?
(Would such systems still have a single-user mode/runlevel available?)
On 2026-01-23 6:33 p.m., Nuno Silva wrote:
It depends on the setting of DEFAULT_HOME in /etc/login.defs. If it is
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
set to "no" the login attempt will fail in the absence of their home directory. If set to "yes", the login attempt will succeed and the user
will land in / instead of $HOME.
So the behaviour can be controlled by the system administrator.
On 1/23/26 13:45, Carlos E.R. wrote:
On 2026-01-23 22:18, Eli the Bearded wrote:
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
At least in openSUSE. No /home, no login, it silently fails (at
least in
graphical mode).
Graphical mode. That could be your problem. But that's fixable with a
a little care for your X11 config. With no xsession or xinit files, it
should spin up a single xterm, maybe with twm. Wayland probably hasn't
got a fallback.
If you can not login, you can not fix anything.
I don't remember the details, it was years ago. The point is that I
want every possibility available, in case something goes wrong. I want
to be able to login as root graphically, just in case.
I just tried in a fresh install of 16.0, and I can login as root into
XFCE. Yellow background. Perfect. Not even a warning message. Not that
I will use it, but I like that the decision is mine to take.
ÿÿÿÿWell if you cannot boot up from the fixed disk have you tried using an installation media?ÿ PCLinuxOS for example has a lot of useful tool. to
help
recover a problematic system.ÿ If a system can be booted up then you have
a chance to correct the problems with the install if it is not a hardware problem.ÿ Hardware problem include a failing fixed disk and/or Graphical Processing Unit which has been assigned a bad or improper driver.
In the PCLinuxOS forum failure to choose the correct GPU driver
usually a nVidia card, is a frequent complaint.
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /home populated before you mount the
real home volume over it
The Natural Philosopher <tnp@invalid.invalid> writes:
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /home populated before you mount the
real home volume over it
Or apply the KISS principle and have /home on the root partition.
On 24/01/2026 14:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 23/01/2026 23:33, Nuno Silva wrote:Or apply the KISS principle and have /home on the root partition.
What's still puzzling me here is that passwd and shadow are under /etc, >>>> so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /home populated before you mount the
real home volume over it
The problem with that is upgrades. You really want /home out of the
way.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 24/01/2026 14:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 23/01/2026 23:33, Nuno Silva wrote:Or apply the KISS principle and have /home on the root partition.
What's still puzzling me here is that passwd and shadow are under /etc, >>>>> so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /home populated before you mount the >>>> real home volume over it
The problem with that is upgrades. You really want /home out of the
way.
In-place upgrades don?t normally touch /home. I?ve been doing upgrades
for 30Y without isolating /home and never once has that been a problem.
If your idea of an upgrade is to delete everything and reinstall from
scratch then that might be another matter, but even then, the worst case
is you recover /home from backup.
Richard Kettlewell wrote this post by blinking in Morse code:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 24/01/2026 14:15, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 23/01/2026 23:33, Nuno Silva wrote:Or apply the KISS principle and have /home on the root partition.
What's still puzzling me here is that passwd and shadow are under /etc, >>>>>> so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /home populated before you mount the >>>>> real home volume over it
The problem with that is upgrades. You really want /home out of the
way.
In-place upgrades don?t normally touch /home. I?ve been doing upgrades
for 30Y without isolating /home and never once has that been a problem.
If your idea of an upgrade is to delete everything and reinstall from
scratch then that might be another matter, but even then, the worst case
is you recover /home from backup.
I periodically scp /home/me to another computer or to an external
drive.
One issue nags me as the years go by... what will happen to all
that data [photos, code, legal documents] when I croak?
:-(
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /homeÿ populated before you mount the
real home volume over it
On 2026-01-24 12:11, The Natural Philosopher wrote:
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /homeÿ populated before you mount
the real home volume over it
That way a user might not know that /home is not mounted, create files
on root partition until it fills up, and later have problems
recovering the files in either place.
The best thing if /home can not be mounted is to crash. Have the user
solve the situation however he sees fit, which can be to use root
instead. His decision then.
On 2026-01-24 12:11, The Natural Philosopher wrote:
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc,
so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /homeÿ populated before you mount the
real home volume over it
That way a user might not know that /home is not mounted, create files
on root partition until it fills up, and later have problems recovering
the files in either place.
The best thing if /home can not be mounted is to crash. Have the user
solve the situation however he sees fit, which can be to use root
instead. His decision then.
On 2026-01-25, Carlos E.R. wrote:
On 2026-01-24 12:11, The Natural Philosopher wrote:
On 23/01/2026 23:33, Nuno Silva wrote:
What's still puzzling me here is that passwd and shadow are under /etc, >>>> so... login should work regardless of /home being mounted or not?
Many configurations are stored in /home/username
The answer is to have a skelatal /homeÿ populated before you mount
the real home volume over it
That way a user might not know that /home is not mounted, create files
on root partition until it fills up, and later have problems
recovering the files in either place.
The best thing if /home can not be mounted is to crash. Have the user
solve the situation however he sees fit, which can be to use root
instead. His decision then.
Have the graphical login manager (if this is the problem here) depend on
the service/script which mounts filesystems and fail if /home does not
get mounted, or if the script has any failure, leaving you with just the virtual console terminal emulators?
That way you know something is amiss. What fails here is if you're still
able to graphically login as root and you want the login screen
available for that.
Normally systemd drops the machine into emergency mode.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Normally systemd drops the machine into emergency mode.
I hate when that happens. I'd prefer the system to continue the boot
attempt as far as it would go, as there is a chance that I might at
least be able to log in SOME way other than entering the root
password? on the consoleý.
"Carlos E.R." <robin_listas@es.invalid> wrote:
Normally systemd drops the machine into emergency mode.
I hate when that happens. I'd prefer the system to continue the boot
attempt as far as it would go, as there is a chance that I might at
least be able to log in SOME way other than entering the root
password? on the consoleý.
Greetings
Marc
? the one that noone knows
ý the one that needs special hardware or walking over to access
On 2026-01-27 09:02, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
Normally systemd drops the machine into emergency mode.
I hate when that happens. I'd prefer the system to continue the boot
attempt as far as it would go, as there is a chance that I might at
least be able to log in SOME way other than entering the root
password? on the consoleý.
You can add "nofail" to the fstab entry. Then boot will continue, but it >also will give no message at all.
At Tue, 27 Jan 2026 09:02:22 +0100, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
Normally systemd drops the machine into emergency mode.
I hate when that happens. I'd prefer the system to continue the boot
attempt as far as it would go, as there is a chance that I might at
least be able to log in SOME way other than entering the root
password? on the consoleý.
Greetings
Marc
? the one that noone knows
ý the one that needs special hardware or walking over to access
I <3 IPMI
Or apply the KISS principle and have /home on the root partition.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Or apply the KISS principle and have /home on the root partition.
My "KISS" principles have me keep /home on a separate drive, so I can
move it between devices easily. When I has having computer issues
earlier this year, I could just pop /home out and put it on an older
computer while I fixed the hardware problem.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 19:03:47 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 367 |
| D/L today: |
540 files (253M bytes) |
| Messages: | 70,845 |
| Posted today: | 26 |