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.
I am using the rsync:// syntax, and I don't remember opening another
port than 22. :-?
I would have to check
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. :-?
On Sat, 17 Jan 2026 03:49:37 +0100, Carlos E.R. wrote:
I am using the rsync:// syntax, and I don't remember opening another
port than 22. :-?
I would have to check
I’ve never found a use for the rsyncd protocol, and I don’t think
anyone would recommend its use for anything serious any more. Just
look at the description <https://manpages.debian.org/rsyncd.conf(5)>:
it uses a laughably weak authentication handshake, and the data
transfer isn’t even encrypted.
SSH is the way to go.
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?
I will admit I like 192.168.1.102 better than fe80::e8fa:7f5c:da23:aa05.
I suppose with enough fucking around I could get sftp to work with IPv6 on >my LAN but I see absolutely no reason to.
You will never be forced to use IPv6 in your LAN. I have IPv6 in my LAN,
but I don't have to use it.
On 2026-01-16 22:07, Lawrence D’Oliveiro wrote:
(just remember you can’t abbreviate it to “ip-addr”).
All that slower than simply calling again ifconfig.
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...
rsync can run without SSH. scp and sftp are still there. 'slogin'
disappeared for reasons I've since forgotten. scp is more for one file
while rsync is for many.
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of
salt. Variances per distributions. It is true in openSUSE.
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
"Carlos E.R." <robin_listas@es.invalid> wrote:
You will never be forced to use IPv6 in your LAN. I have IPv6 in my LAN,
but I don't have to use it.
I bet you're already using it more than you think.
I am forced to still use IPv4. That's bad.
My ISP started a Beta test, but I had to stop it. The router did not
have a firewall for IPv6 or was disabled.
"Carlos E.R." <robin_listas@es.invalid> writes:
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH.
Personally I have never bothered with rsyncd...
AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of
salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
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?
"Carlos E.R." <robin_listas@es.invalid> wrote:
My ISP started a Beta test, but I had to stop it. The router did not
have a firewall for IPv6 or was disabled.
That's the fault of your Router. Get gear that is worth its money.
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).
On 2026-01-17 15:06, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
My ISP started a Beta test, but I had to stop it. The router did not
have a firewall for IPv6 or was disabled.
That's the fault of your Router. Get gear that is worth its money.
You forget that it is THEIR router, not mine. I can not just get a router.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-17 15:06, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
My ISP started a Beta test, but I had to stop it. The router did not
have a firewall for IPv6 or was disabled.
That's the fault of your Router. Get gear that is worth its money.
You forget that it is THEIR router, not mine. I can not just get a router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
In your case, you'd need your own ethernet-ethernet router with an
IPv6 firewall. It also needs to support IPv6 DHCP PD (and your ISP
needs to do that as well, which requires them to have a basic clue
about IPv6).
"Carlos E.R." <robin_listas@es.invalid> wrote:
You forget that it is THEIR router, not mine. I can not just get a
router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
On Sun, 18 Jan 2026 11:13:44 +0100, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
You forget that it is THEIR router, not mine. I can not just get a
router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
Carlos is in Spain. 😑
Here in NZ, we have a decently competitive Internet provider market,
too, like you have in Germany.
Jack Wallen’s list ><https://www.zdnet.com/article/linux-commands-deprecated-why-do-not-use/>
of commands you shouldn’t be using any more, and what to use instead,
is a mixed bag.
ifconfig/iwconfig vs ip/iw -- the latter newer ones (part of the Linux >“iproute2” suite) offer greater access to all the features of the
Linux network stack than the former, older ones, and so are preferable
in lots of ways. It is already possible to find setups which don’t
have the old commands installed by default; I’m not sure if any
distros have actually dropped the option for installing them
altogether, but no doubt that will happen at some point.
scp -- wrong. rsync, scp and sftp are all different ways of
transferring files securely over SSH. scp did use to use its own
protocol at one point, but it has been upgraded to use the same
underlying protocol as sftp, so it’s perfectly fine to continue using
the same command, if that’s what you’re used to. There is no sign that >the scp command itself is going to be deprecated at any point, though
no doubt the option to fall back to the old protocol for
compatibility’s sake is likely to be removed eventually.
egrep/fgrep -- it has been true for decades (possibly has always been
true for the GNU utilities?) that egrep and fgrep are just synonyms
for “grep -E” and “grep -F” respectively. And it is true that the >alternative names are finally being deprecated after all these years,
so it behooves you to learn to use the “grep” command for all forms.
netstat vs ss -- yes, another case of the newer iproute2-based command
taking over from the older, traditional command, and offering more
features besides. Same remarks as above apply.
route vs ip route -- iproute2 again.
arp vs ip neighbour/neighbor -- more iproute2.
Le 18-01-2026, Lawrence D’Oliveiro <ldo@nz.invalid> a écrit :
On Sun, 18 Jan 2026 11:13:44 +0100, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
You forget that it is THEIR router, not mine. I can not just get a
router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
Carlos is in Spain. 😑
Here in NZ, we have a decently competitive Internet provider market,
too, like you have in Germany.
In France we have a decently correct ISP market too. But it means we can chose our ISP. Mostly the biggest ISP come with their router and we have
to use it. The possibility to choose one's ISP doesn't imply we can
choose our router.
Le 18-01-2026, Lawrence D’Oliveiro <ldo@nz.invalid> a écrit :
On Sun, 18 Jan 2026 11:13:44 +0100, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
You forget that it is THEIR router, not mine. I can not just get
a router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
Carlos is in Spain. 😑
Here in NZ, we have a decently competitive Internet provider
market, too, like you have in Germany.
In France we have a decently correct ISP market too. But it means we
can chose our ISP. Mostly the biggest ISP come with their router and
we have to use it. The possibility to choose one's ISP doesn't imply
we can choose our router.
On 2026-01-18 22:15, Stéphane CARPENTIER wrote:
Le 18-01-2026, Lawrence D’Oliveiro <ldo@nz.invalid> a écrit :
On Sun, 18 Jan 2026 11:13:44 +0100, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
You forget that it is THEIR router, not mine. I can not just get a
router.
Ouch. Please forgive my European-Centric View, where residential
customers HAVE to get the option to choose their own router.
Carlos is in Spain. 😑
Here in NZ, we have a decently competitive Internet provider market,
too, like you have in Germany.
In France we have a decently correct ISP market too. But it means we can
chose our ISP. Mostly the biggest ISP come with their router and we have
to use it. The possibility to choose one's ISP doesn't imply we can
choose our router.
Absolutely, same situation in Spain.
Anyway, the context was a beta testing of IPv6, and I proved that at
lest one of the provided routers was not IPv6 ready. It did not activate
a firewall for IPv6.
I reported this, and they did some thing that closed all incoming IPv6 connections to my machines. Input ssh directly to a machine in my LAN
from outside became impossible in IPv6, and no means to open it up. And
that is a crucial feature of IPv6: no needing to use NAT and tricks in
the router to connect from outside to a machine inside.
In NZ, and I presume in Germany, too, the company that manages the
physical fibre connection is not an ISP, and is not allowed to become
an ISP.
A general rule of conservative programming is 'don't learn anything
new until the old way simply does not work'
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
In NZ, and I presume in Germany, too, the company that manages the
physical fibre connection is not an ISP, and is not allowed to become
an ISP.
No, in Gemany the fiber optic company can be the ISP as well, and in
some situations they are not even required to allow competitors on
their network. That requirement only appears if the line owner's
market share is so high that it is considered dominant.
That's really bad, since especially the smaller fiber companies don't
have much clue about to run a network, to install connections at scale
and to keep a decent service both regarding moving packets and fixing problems. The one thing that the fiber companies can to well is lying
at the customer, for example sending sales people from door to door
with the news that the residents MUST buy fiber because their DSL will
be turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
We already had that issue with DSL 20 years ago and didn't learn
anything from that. The DSL companies have learned their ropes, so
there is hope that the fiber companies will, eventually.
Greetings
Marc
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH.
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of
salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
Jack Wallen’s list <https://www.zdnet.com/article/linux-commands-deprecated-why-do-not-use/>
of commands you shouldn’t be using any more, and what to use instead,
is a mixed bag.
ifconfig/iwconfig vs ip/iw -- the latter newer ones (part of the Linux
....
scp -- wrong. rsync, scp and sftp are all different ways of
...
egrep/fgrep -- it has been true for decades (possibly has always been
....
netstat vs ss -- yes, another case of the newer iproute2-based command
....
route vs ip route -- iproute2 again.
arp vs ip neighbour/neighbor -- more iproute2.
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
In NZ, and I presume in Germany, too, the company that manages the
physical fibre connection is not an ISP, and is not allowed to become
an ISP.
No, in Gemany the fiber optic company can be the ISP as well, and in
some situations they are not even required to allow competitors on
their network. That requirement only appears if the line owner's
market share is so high that it is considered dominant.
That's really bad, since especially the smaller fiber companies don't
have much clue about to run a network, to install connections at scale
and to keep a decent service both regarding moving packets and fixing problems. The one thing that the fiber companies can to well is lying
at the customer, for example sending sales people from door to door
with the news that the residents MUST buy fiber because their DSL will
be turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
We already had that issue with DSL 20 years ago and didn't learn
anything from that. The DSL companies have learned their ropes, so
there is hope that the fiber companies will, eventually.
On 17.01.2026 10:53 The Natural Philosopher wrote:
A general rule of conservative programming is 'don't learn anything
new until the old way simply does not work'
This is already the case. E.g. SUSE doesn't come with ifconfig, arp,
route etc. preinstalled. And in case network is not set up, you cannot install them.
On 1/17/26 18:20, The Natural Philosopher wrote:
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH.
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of
salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba shares, to ssh/rsync (due to symlink issues). I fell at the first hurdle of how to
have root access on both local and remote host. Eventually I created a
new remote user account with passwordless sudo, specifically for rsync.
The solution seemed a bit crap. It seemed that such a common usecase
should be better documented, like I was missing something.
Does rsyncd solve this root access problem? Is it a better/more orthodox solution.
I could potentially use nfs, but I do still use Windows occasionally, so would like access from Windows, I did briefly consider dual shares using both Samba and nfs.
On 1/17/26 18:20, The Natural Philosopher wrote:
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH.
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of
salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba shares, to ssh/rsync (due to symlink issues). I fell at the first hurdle of how to
have root access on both local and remote host. Eventually I created a
new remote user account with passwordless sudo, specifically for rsync.
The solution seemed a bit crap. It seemed that such a common usecase
should be better documented, like I was missing something.
Does rsyncd solve this root access problem? Is it a better/more orthodox solution.
I could potentially use nfs, but I do still use Windows occasionally, so would like access from Windows, I did briefly consider dual shares using both Samba and nfs.
On 2026-01-19 12:15, Marco Moock wrote:
On 17.01.2026 10:53 The Natural Philosopher wrote:
A general rule of conservative programming is 'don't learn anything
new until the old way simply does not work'
This is already the case. E.g. SUSE doesn't come with ifconfig, arp,
route etc. preinstalled. And in case network is not set up, you cannot
install them.
You can have your little cheat sheet, and during installation install
the list of add on packages that you want to have from the first minute
that are not installed by default. Say, I like midnight commander.
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with the
news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will be
without Internet if they don't sign up with the fiber company.
I always find it interesting how much people are willing to learn and
work for not having to adapt to the important things they SHOULD
learn.
In France we have a decently correct ISP market too. But it means we can chose our ISP. Mostly the biggest ISP come with their router and we haveWhy do you have to use it? Here in NY, we have cable and fiber and maybe
to use it. The possibility to choose one's ISP doesn't imply we can
choose our router.
I'm currently looking at moving from backing up data on Samba
shares, to ssh/rsync (due to symlink issues). I fell at the first
hurdle of how to have root access on both local and remote host.
I always find it interesting how much people are willing to learn
and work for not having to adapt to the important things they SHOULD
learn.
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
The router is not only an internet router: it also converts VoIP to
a standard copper pair connection where I connect my house landline.
It's astonishing how blatant salesgoons are about this kind of
thing. When $EMPLOYER got acquired by another company a few years
back, we had a competitor running around telling customers our
product was "going away" and even pretending to be the official
replacement. Naturally, they said this over the phone rather than in
an e-mail, so we never got anything legally actionable on them...
It's just a change of syntax.
Still here as of this writing, ~4.5 years later.It's astonishing how blatant salesgoons are about this kind of
thing. When $EMPLOYER got acquired by another company a few years
back, we had a competitor running around telling customers our
product was "going away" and even pretending to be the official replacement. Naturally, they said this over the phone rather than in
an e-mail, so we never got anything legally actionable on them...
How soon after that *did* the product go away ... ?
You really think "buy out and shut down competitor" is not a commonSure is! But given that it was *our competitors* making materially
business tactic?
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.
On Mon, 19 Jan 2026 14:21:39 +0100, Carlos E.R. wrote:
The router is not only an internet router: it also converts VoIP to
a standard copper pair connection where I connect my house landline.
In our case, the “ONT” box that terminates the fibre has separate connections for phone landline versus Internet. The former goes
straight into a handset or handsets, while the latter is a standard
Ethernet connector that goes straight into my store-bought router.
The router says the Internet connection type is “Dynamic IP”, which I gather just means regular DHCP. So I could set up a Linux box, with a suitable accoutrement of Ethernet interfaces, in its stead, to operate--
my own homebrew Internet router.
Characters to type:ip l
ifconfig
ip link show
On 2026-01-19 12:45, Pancho wrote:
On 1/17/26 18:20, The Natural Philosopher wrote:
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not
use SSH.
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a
pinch of salt. Variances per distributions. It is true in
openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba
shares, to ssh/rsync (due to symlink issues). I fell at the first
hurdle of how to have root access on both local and remote host.
Eventually I created a new remote user account with passwordless
sudo, specifically for rsync. The solution seemed a bit crap. It
seemed that such a common usecase should be better documented, like
I was missing something.
You can configure to access ssh as root without typing a password.
With key pairs, and have an agent remember the phrase for you, or
have none.
Does rsyncd solve this root access problem? Is it a better/more
orthodox solution.
Yes, rsyncd does this.
On Mon, 19 Jan 2026 09:54:15 +0100, Marc Haber wrote:
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
In our case that’s no lie. The copper network is being decommissioned, >region by region, and DSL along with it.
There is this stereotype of the Germans being well-organized; I can’t
help feeling that NZ has outdone them in this one instance, of
managing the transition to fibre. ?
On Mon, 19 Jan 2026 15:50:56 +0100
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
I always find it interesting how much people are willing to learn and
work for not having to adapt to the important things they SHOULD
learn.
Not everyone agrees that they *should* have to learn it.
On Mon, 19 Jan 2026 15:50:56 +0100, Marc Haber wrote:
I always find it interesting how much people are willing to learn
and work for not having to adapt to the important things they SHOULD
learn.
The incremental cost of continual workarounds to avoid having to do
things the new way inevitably adds up to more than the up-front cost
of starting out doing things the new way in the first place.
On Mon, 19 Jan 2026 11:45:07 +0000, Pancho wrote:
I'm currently looking at moving from backing up data on Samba
shares, to ssh/rsync (due to symlink issues). I fell at the first
hurdle of how to have root access on both local and remote host.
With SSH, you can set up trust keys, using the authorized_keys file,
so a given account on one machine can accept access from one or more
accounts on other machines without needing a password.
I'm currently looking at moving from backing up data on Samba shares,
to ssh/rsync (due to symlink issues).
I could potentially use nfs, but I do still use Windows occasionally,
so would like access from Windows, I did briefly consider dual shares
using both Samba and nfs.
but theThe asymmetry results from traffic analysis done in the early days of 'consumer Internet'.
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies,
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
On Mon, 19 Jan 2026 09:54:15 +0100, Marc Haber wrote:
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
In our case that’s no lie. The copper network is being decommissioned,
region by region, and DSL along with it.
Over here it's still a few years until then. I had TWO of those sales
people stopping by my place in the last six weeks, all claiming that I
need to sign up with their fiber RIGHT NOW to avoid my Internet from
being canceled under my feet.
My street doesn't even have the fiber-to-the-home laid yet (we have
the multicore conduit, but neither the building branch lines nor the
actual fiber in there yet), what they claim to be fiber is exactly the
same service they're selling right now,
fiber-to-the-curb-with-last-mile-DSL für one of them, and fiber-to-the-neighborhood-with-last-mile-coax for the other.
The fiber-to-the-neighborhood-with-last-mile-coax company is even
unlikely to get access to the fiber-to-the-home infrastructure once
it's been built.
There is this stereotype of the Germans being well-organized; I can’t
help feeling that NZ has outdone them in this one instance, of
managing the transition to fibre. ?
I have to admit that we used to be well-organized, but especially
regarding public matters we lost it in the last decade. In the early
1980es, political corruption made us settle to running coax-based
copper cable TV to the buildings instead of doing fiber, and we're
still suffering from that mistake. The majority of residential
Internet here is DSL, with VDSL vectoring having re-monopolized the
market ten years ago, with some neighborhoods having copper coax cable providing an alternative for broadband.
We're building fiber like crazy and spending insane amounts of money,
but it'll be a couple of years until we'll have parity between the
copper technologies and fiber.
And, frankly speaking, I don't see the necessity of replacing existing
copper broadband with fiber. For example, I work online, I would be
lost without Internet at home, but I don't even have the maximum
bandwith plan that my technology (VDSL vectoring) offers. I would
change to another plan if it offered more upstream bandwidth, but the
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies, so fiber doesn't really have an
advantage for me (aside from less power demand and a few milliseconds
of less latency).
That being said, I'm going to have the fiber laid in the very second I
can have it laid, but that's mainly to keep the value of the real
estate (and I plan to use the digging activities to put a fat power
cable out there since the next car I buy will surely be electric).
On 20/01/2026 09:46, Marc Haber wrote:
but theThe asymmetry results from traffic analysis done in the early days of >'consumer Internet'.
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies,
On 2026-01-20 10:46, Marc Haber wrote:
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
On Mon, 19 Jan 2026 09:54:15 +0100, Marc Haber wrote:
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
In our case that’s no lie. The copper network is being decommissioned, >>> region by region, and DSL along with it.
Over here it's still a few years until then. I had TWO of those sales
people stopping by my place in the last six weeks, all claiming that I
need to sign up with their fiber RIGHT NOW to avoid my Internet from
being canceled under my feet.
Are they from your ISP?
It doesn't matter if there is no advantage, copper exchanges were
disabled and then removed, and the premises sold or rented.
That being said, I'm going to have the fiber laid in the very second I
can have it laid, but that's mainly to keep the value of the real
estate (and I plan to use the digging activities to put a fat power
cable out there since the next car I buy will surely be electric).
:-)
In my case, the fibre and the power are on the walls.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 20/01/2026 09:46, Marc Haber wrote:
but theThe asymmetry results from traffic analysis done in the early days of
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies,
'consumer Internet'.
Both DOCSIS and VDSL vectoring can't do symmetric. They rely on the
high data rate going from the central point to the branches.
Greetings--
Marc
On 20/01/2026 13:34, Marc Haber wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:It's not a question of 'cant': They were *deliberately designed not to*.
On 20/01/2026 09:46, Marc Haber wrote:
but theThe asymmetry results from traffic analysis done in the early days of
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies,
'consumer Internet'.
Both DOCSIS and VDSL vectoring can't do symmetric. They rely on the
high data rate going from the central point to the branches.
And they don't 'rely' on anything other than a piece of [coaxial?] wire.
The issue is that the total bandwidth (up + down) is limited. So you
select a protocol that fits most customers usage the best.
ADSL, VDSL and DOCSIS reflect that *choice*.
Back in the day we used other serial protocols that were symmetric. Like >ISDN
On 2026-01-20 10:46, Marc Haber wrote:
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
On Mon, 19 Jan 2026 09:54:15 +0100, Marc Haber wrote:
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be
turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
In our case that’s no lie. The copper network is being decommissioned, >>> region by region, and DSL along with it.
Over here it's still a few years until then. I had TWO of those sales
people stopping by my place in the last six weeks, all claiming that I
need to sign up with their fiber RIGHT NOW to avoid my Internet from
being canceled under my feet.
Are they from your ISP?
Here, they did not come. They phoned and simply offered an improvement.
I had TV via encoded pay satellite. They made an offer that was actually cheaper including TV, land line, internet, and mobile phone. Years
before my neighbours were forced to change.
I could see that the multiplexer box had only three clients in my block.
My street doesn't even have the fiber-to-the-home laid yet (we have
the multicore conduit, but neither the building branch lines nor the
actual fiber in there yet), what they claim to be fiber is exactly the
same service they're selling right now,
fiber-to-the-curb-with-last-mile-DSL für one of them, and
fiber-to-the-neighborhood-with-last-mile-coax for the other.
The fiber-to-the-neighborhood-with-last-mile-coax company is even
unlikely to get access to the fiber-to-the-home infrastructure once
it's been built.
There is this stereotype of the Germans being well-organized; I can’t
help feeling that NZ has outdone them in this one instance, of
managing the transition to fibre. ?
I have to admit that we used to be well-organized, but especially
regarding public matters we lost it in the last decade. In the early
1980es, political corruption made us settle to running coax-based
copper cable TV to the buildings instead of doing fiber, and we're
still suffering from that mistake. The majority of residential
Internet here is DSL, with VDSL vectoring having re-monopolized the
market ten years ago, with some neighborhoods having copper coax cable
providing an alternative for broadband.
We're building fiber like crazy and spending insane amounts of money,
but it'll be a couple of years until we'll have parity between the
copper technologies and fiber.
And, frankly speaking, I don't see the necessity of replacing existing
copper broadband with fiber. For example, I work online, I would be
lost without Internet at home, but I don't even have the maximum
bandwith plan that my technology (VDSL vectoring) offers. I would
change to another plan if it offered more upstream bandwidth, but the
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies, so fiber doesn't really have an
advantage for me (aside from less power demand and a few milliseconds
of less latency).
Not here. I have 1G in both directions. Up to, that's the key word,
because GPON divides the total bandwidth between the clients.
It doesn't matter if there is no advantage, copper exchanges were
disabled and then removed, and the premises sold or rented.
That being said, I'm going to have the fiber laid in the very second I
can have it laid, but that's mainly to keep the value of the real
estate (and I plan to use the digging activities to put a fat power
cable out there since the next car I buy will surely be electric).
:-)
In my case, the fibre and the power are on the walls.
One reason to replace copper with fibre or fiber optical in
either case is that accessiblem lower voltage copper is being stolen
from public facilities.
It is resold to dealers in junk and recycling. It is a problem in
Bay Area Cities.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-20 10:46, Marc Haber wrote:
Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
On Mon, 19 Jan 2026 09:54:15 +0100, Marc Haber wrote:
The one thing that the fiber companies can to well is lying at the
customer, for example sending sales people from door to door with
the news that the residents MUST buy fiber because their DSL will be >>>>> turned off and decommissioned "later this year" and that they will
be without Internet if they don't sign up with the fiber company.
In our case that’s no lie. The copper network is being decommissioned, >>>> region by region, and DSL along with it.
Over here it's still a few years until then. I had TWO of those sales
people stopping by my place in the last six weeks, all claiming that I
need to sign up with their fiber RIGHT NOW to avoid my Internet from
being canceled under my feet.
Are they from your ISP?
No. But of course they claim that I am already their customer. I'm
probably the only one in the street who does immediately spot that
lie.
It doesn't matter if there is no advantage, copper exchanges were
disabled and then removed, and the premises sold or rented.
That what used to be the copper exchange holding the telephony stuff
is gone already, we have MSANs (Multi Service Access Nodes) on the
curb where the fiber lines terminate and the VDSL vectoring lines
(usually just a couple of hundred meters long) branch out. VDSL
vectoring can do 250/40.
That being said, I'm going to have the fiber laid in the very second I
can have it laid, but that's mainly to keep the value of the real
estate (and I plan to use the digging activities to put a fat power
cable out there since the next car I buy will surely be electric).
:-)
In my case, the fibre and the power are on the walls.
Everyhing buried here.
On 2026-01-20, Bobbie Sellers <bliss-sf4ever@dslextreme.com> wrote:
One reason to replace copper with fibre or fiber optical in
either case is that accessiblem lower voltage copper is being stolen
from public facilities.
It is resold to dealers in junk and recycling. It is a problem in
Bay Area Cities.
We've had a rash of thefts up here too. There's been a mention
of keeping a close eye on recycling depots to try to catch the
thieves.
The worst part is that some of the easiest copper to steal
is ground wire. We can only hope that the thieves get zapped
before some innocent victim does.
I rather enjoy symlinks in Windows these days, in msys2. Although
they're weirdly restricted, either need admin rights or need to turn
on "developer mode" to just create them.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 20/01/2026 13:34, Marc Haber wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:It's not a question of 'cant': They were *deliberately designed not to*.
On 20/01/2026 09:46, Marc Haber wrote:
but theThe asymmetry results from traffic analysis done in the early days of
fiber operators artificially emulate the absurdly asymmetric plans
from the legacy technologies,
'consumer Internet'.
Both DOCSIS and VDSL vectoring can't do symmetric. They rely on the
high data rate going from the central point to the branches.
And they don't 'rely' on anything other than a piece of [coaxial?] wire.
The issue is that the total bandwidth (up + down) is limited. So you
select a protocol that fits most customers usage the best.
I am really impressed by your technical knowledge.
Can you explain how VDSL Vectoring with high bandwidth from the
branches to the central point would know about the traffic on the
other pairs to be able to appropriately distort the signal on the one
pair so that it arrives in a readable change?
ADSL, VDSL and DOCSIS reflect that *choice*.
Back in the day we used other serial protocols that were symmetric. Like
ISDN
When we still believed that a twisted pair of subscriber line would be limited to like 3,5 kHz of bandwidth.
Greetings--
Marc
On 2026-01-20 20:01, Charlie Gibbs wrote:
On 2026-01-20, Bobbie Sellers <bliss-sf4ever@dslextreme.com> wrote:
One reason to replace copper with fibre or fiber optical in
either case is that accessiblem lower voltage copper is being stolen
from public facilities.
It is resold to dealers in junk and recycling. It is a problem in
Bay Area Cities.
Yes, here too, but phone copper wires are way too thin, or with lots of insulation, it is not profitable work.
Sometimes they steal the power wire of trains, leaving them stranded in
the middle of nowhere.
We've had a rash of thefts up here too. There's been a mention
of keeping a close eye on recycling depots to try to catch the
thieves.
The worst part is that some of the easiest copper to steal
is ground wire. We can only hope that the thieves get zapped
before some innocent victim does.
Some have. :-}
On 2026-01-19 12:45, Pancho wrote:
On 1/17/26 18:20, The Natural Philosopher wrote:
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH. >>>>
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of >>>>> salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba shares,
to ssh/rsync (due to symlink issues). I fell at the first hurdle of
how to have root access on both local and remote host. Eventually I
created a new remote user account with passwordless sudo, specifically
for rsync. The solution seemed a bit crap. It seemed that such a
common usecase should be better documented, like I was missing something.
You can configure to access ssh as root without typing a password. With
key pairs, and have an agent remember the phrase for you, or have none.
At Mon, 19 Jan 2026 14:27:28 +0100, "Carlos E.R."
<robin_listas@es.invalid> wrote:
On 2026-01-19 12:45, Pancho wrote:
On 1/17/26 18:20, The Natural Philosopher wrote:
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not
use SSH.
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a
pinch of salt. Variances per distributions. It is true in
openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba
shares, to ssh/rsync (due to symlink issues). I fell at the first
hurdle of how to have root access on both local and remote host.
Eventually I created a new remote user account with passwordless
sudo, specifically for rsync. The solution seemed a bit crap. It
seemed that such a common usecase should be better documented, like
I was missing something.
You can configure to access ssh as root without typing a password.
With key pairs, and have an agent remember the phrase for you, or
have none.
I thought I'd jump in here, and point out that you can have
a passphraseless secret key on the client, and set the key
in authorized_keys to only be able to run a single command
(or a set of commands).
On 19/01/2026 11:45, Pancho wrote:
On 1/17/26 18:20, The Natural Philosopher wrote:I had to look up what I in fact did..
On 17/01/2026 13:11, Richard Kettlewell wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:Ah. I do. None of my data is private that is being stored remotely
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 ofAre they? even if you run rsyncd?
transferring files securely over SSH.
If you tell it to connect to an rsyncd then indeed it does not use SSH. >>>>
Personally I have never bothered with rsyncd...
I think it is straight streaming of bytes and that is it.AFAIK yes, the transfer happens of the ssh port with ssh type of
encryption. That is what the article says, so take it with a pinch of >>>>> salt. Variances per distributions. It is true in openSUSE.
The zdnet article says nothing about what protocol rsync uses.
Locally i have nfs mounts to move data around.
So I don't really use ssh protocols to copy data at all.
I'm currently looking at moving from backing up data on Samba shares,
to ssh/rsync (due to symlink issues). I fell at the first hurdle of
how to have root access on both local and remote host. Eventually I
created a new remote user account with passwordless sudo, specifically
for rsync. The solution seemed a bit crap. It seemed that such a
common usecase should be better documented, like I was missing something.
Does rsyncd solve this root access problem? Is it a better/more
orthodox solution.
I have a remote user rsync. With a password. This is place in an env variable in the backup script
e,g.
RSYNC_PASSWORD=mainly.crap
export RSYNC_PASSWORD
rsync -Cavxz --delete rsync@remote.host::vp1/etc /backup2/vp1
On the remote host is this
$ more /etc/rsyncd.conf
[vp1]
path=/
Comment = get server
uid = root
gid = root
read only = true
use chroot = yes
auth users = rsync
secrets file = /etc/rsyncd.secrets
and in the /etc/rsyncd.secrets file is
rsync:mainly.crap
rsync is invoked via inet
inetd.conf
rsync stream tcp nowait root /usr/bin/rsync rsyncd
--daemon
and /etc/services...
rsync 873/tcp
rsync 873/udp
I could potentially use nfs, but I do still use Windows occasionally,
so would like access from Windows, I did briefly consider dual shares
using both Samba and nfs.
I am not sure there is an rsync client for windows.
Pancho <Pancho.Jones@protonmail.com> writes:
I'm currently looking at moving from backing up data on Samba shares,
to ssh/rsync (due to symlink issues).
So what's the status there, Samba and symlinks? I rather enjoy symlinks
in Windows these days, in msys2. Although they're weirdly restricted,
either need admin rights or need to turn on "developer mode" to just
create them.
I could potentially use nfs, but I do still use Windows occasionally,
so would like access from Windows, I did briefly consider dual shares
using both Samba and nfs.
I've tried the NFS client support in Windows but it didn't impress. It
has been a while though, I think it was in the Windows 7 and early
Windows 10 times.
sshfs has been enough for my needs for Linux fs access from Windows and
I do my Windows backups from Linux, mostly.
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.
AIUI, modern security advice is to not have an interactive root
account, i.e. with a password.
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...
On Wed, 21 Jan 2026 00:32:29 +0000, Pancho wrote:
AIUI, modern security advice is to not have an interactive root
account, i.e. with a password.
An interactive account doesn’t have to have a password.
Even if you configure a root password, you can configure SSH to
specifically disallow using it for remote access.
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
On 20/01/2026 15:14, Marc Haber wrote:
Can you explain how VDSL Vectoring with high bandwidth from theLook it up. its not exactly rocket science.
branches to the central point would know about the traffic on the
other pairs to be able to appropriately distort the signal on the one
pair so that it arrives in a readable change?
When we still believed that a twisted pair of subscriber line would be
limited to like 3,5 kHz of bandwidth.
You really have got your knickers in a twist.
I only said ISDN because I suspected that uis all you would know about.
There was T1, or E1, for a start. And T2 and T3.
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
I am not sure that duplicates roots environment exactly.
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
On 21/01/2026 08:58, Pancho wrote:
sudo bash
I am not sure that duplicates roots environment exactly.
On 1/21/26 04:17, Lawrence D’Oliveiro wrote:
On Wed, 21 Jan 2026 00:32:29 +0000, Pancho wrote:
AIUI, modern security advice is to not have an interactive root
account, i.e. with a password.
An interactive account doesn’t have to have a password.
Even if you configure a root password, you can configure SSH to
specifically disallow using it for remote access.
Yes, which I don't have, and was specifically trying to avoid having in
this instance for rsync. It is probably how most people do it in real life.
If you delay an emergency solution significantly by five keystrokes
per action that you're too slow a typist anyway.
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
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.
On 2026-01-21 09:58, Pancho 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
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
On 1/21/26 13:04, Carlos E.R. wrote:
On 2026-01-21 09:58, Pancho wrote:Funny I have had situations where /home could not be mounted but was able
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.I always enable one.
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. >>>>
Sometimes when there is an emergency you need not to have to type
'sudo' to edit every file...
sudo bash
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
to access my root account both via terminal and Desktop Environment.
On PCLOS we must set both root and user passwords on installation.
In the recent past we could use the same password for both but that has been corrected. Probably a good thing...
We cannot start up in
the root account but access is available to most functions restricted to
root via terminal and GUI. From the Boot we can choose to enter
root terminal and I have not checked because I have enough to deal
with in RL but formerly we could login to root via terminal then
"startx" but that was not too useful.
bliss- Dell Precision 7730- PCLOS 2026.01- Linux 6.12.66 pclos1- KDE
Plasma 6.5.5
On 2026-01-21 09:58, Pancho 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
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Most Linux distros put the root home directory as /root, not in /home.
openSUSE used by default the same password for both, yes. We had a good
row about this (some argued that it was good enough for home users, and >easier on users coming from Windows), and finally the compromise was to >allow during installation to click somewhere and type a different
password for root.
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Most Linux distros put the root home directory as /root, not in /home.
Yes and on occasion when /home hasn't been available, I've just been
logged in as ordinary user with a note saying something like home
directory not available, using / as home. Of course, can't do much when >system is in such a state but can login as user or root.
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Most Linux distros put the root home directory as /root, not in /home.
Yes and on occasion when /home hasn't been available, I've just been
logged in as ordinary user with a note saying something like home
directory not available, using / as home. Of course, can't do much when system is in such a state but can login as user or root.
On 2026-01-21 09:58, Pancho 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
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
On 2026-01-21 09:58, Pancho wrote:
On 1/21/26 04:16, The Natural Philosopher wrote:
On 21/01/2026 00:32, Pancho wrote:sudo bash
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...
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
"Carlos E.R." <robin_listas@es.invalid> wrote:
openSUSE used by default the same password for both, yes. We had a good
row about this (some argued that it was good enough for home users, and
easier on users coming from Windows), and finally the compromise was to
allow during installation to click somewhere and type a different
password for root.
You didn't have configuration management back then to automate that?
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Most Linux distros put the root home directory as /root, not in /home.
On 2026-01-21 23:50, Lawrence D’Oliveiro wrote:
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you canMost Linux distros put the root home directory as /root, not in
not login as root, nor as anybody, to correct the issue.
/home.
That was a typo. Mind fudge.
I suppose it was:
If the emergency includes that /home can not be mounted, then you can
not login as user, nor as anybody, to correct the issue.
On 2026-01-22, Anssi Saari wrote:
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
On Wed, 21 Jan 2026 22:04:58 +0100, Carlos E.R. wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Most Linux distros put the root home directory as /root, not in /home.
Yes and on occasion when /home hasn't been available, I've just been
logged in as ordinary user with a note saying something like home
directory not available, using / as home. Of course, can't do much when
system is in such a state but can login as user or root.
I was wondering what was this about, but even if root's $HOME ends up
under /home, passwd and shadow are still under /etc, so yes, it should
still not prevent logging in? Or are we missing some detail here?
(Depending on the system (and whether there is encryption and so on), it might also be possible to have a root session without logging in, by replacing sysvinit or systemd (well, whatever gets executed as PID 1) by
a shell. Another approach is to get the disks mounted (possibly taking
into account encryption) from another system and chroot(1).)
On 2026-01-22 10:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
openSUSE used by default the same password for both, yes. We had a good
row about this (some argued that it was good enough for home users, and
easier on users coming from Windows), and finally the compromise was to
allow during installation to click somewhere and type a different
password for root.
You didn't have configuration management back then to automate that?
Automate what, the installation?
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-22 10:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
openSUSE used by default the same password for both, yes. We had a good >>>> row about this (some argued that it was good enough for home users, and >>>> easier on users coming from Windows), and finally the compromise was to >>>> allow during installation to click somewhere and type a different
password for root.
You didn't have configuration management back then to automate that?
Automate what, the installation?
Automate setting passwords to your standards.
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
On Mon, 19 Jan 2026 20:32:25 +0800, Mr. Man-wai Chang wrote:
It's just a change of syntax.
Plus a bunch of new functionality, too.
Think of the reason for change of syntax is keeping things more
regular with the accumulation of new concepts.
On 2026-01-22 21:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-22 10:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
openSUSE used by default the same password for both, yes. We had a good >>>>> row about this (some argued that it was good enough for home users, and >>>>> easier on users coming from Windows), and finally the compromise was to >>>>> allow during installation to click somewhere and type a different
password for root.
You didn't have configuration management back then to automate that?
Automate what, the installation?
Automate setting passwords to your standards.
Why would I need to do that? I am a home user.
every system I have been willing to use in the last 20
years has
made "/"(root) and "/home" in separate partitions. Foolish innovaters
as in Canonical
have allowed "/home" to be mounted only in "/"(root) which is to my
ideas of Linux
is practically disgusting
Bobbie Sellers <bliss-sf4ever@dslextreme.com> wrote:
every system I have been willing to use in the last 20 years has
made "/"(root) and "/home" in separate partitions. Foolish
innovaters as in Canonical have allowed "/home" to be mounted only
in "/"(root) which is to my ideas of Linux is practically
disgusting
I disagree with nearly everything you have written up there,
including the formatting. I don't think it is worth to have further discussion about that here.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-22 21:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2026-01-22 10:43, Marc Haber wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
openSUSE used by default the same password for both, yes. We had a good >>>>>> row about this (some argued that it was good enough for home users, and >>>>>> easier on users coming from Windows), and finally the compromise was to >>>>>> allow during installation to click somewhere and type a different
password for root.
You didn't have configuration management back then to automate that?
Automate what, the installation?
Automate setting passwords to your standards.
Why would I need to do that? I am a home user.
You said "we had a good row", and mentioned a compromise. That led me
to the impression that you were talking about professional work in a
team.
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Really? Not my experience at all. Instead I login and get dumped in /
instead of $HOME
Elijah--
------
HOMEless does not mean unwelcome in Unix
Foolish innovaters as in Canonical have allowed "/home" to be mounted
only in "/"(root) which is to my ideas of Linux is practically
disgusting.
On 2026-01-23 04:33, Eli the Bearded wrote:
In comp.os.linux.misc, Carlos E.R. <robin_listas@es.invalid> wrote:
If the emergency includes that /home can not be mounted, then you can
not login as root, nor as anybody, to correct the issue.
Really? Not my experience at all. Instead I login and get dumped in /
instead of $HOME
Please remember that the above paragraph was a typing error or mind fart
and was corrected later.
If the emergency includes that /home can not be mounted, then you can
not login as any user, to correct the issue.
At least in openSUSE. No /home, no login, it silently fails (at least in graphical mode).
Elijah
------
HOMEless does not mean unwelcome in Unix
Bobbie Sellers <bliss-sf4ever@dslextreme.com> wrote:
Foolish innovaters as in Canonical have allowed "/home" to be mounted
only in "/"(root) which is to my ideas of Linux is practically
disgusting.
I'm curious about this, as all I can find on a brief Web search is discussions of whether and how to set up a separate /home partition on Ubuntu, rather than anything about it being disallowed. (How would you
even *do* that, anyway?)
At least in openSUSE. No /home, no login, it silently fails (at least in graphical mode).
Changing syntax and names can also hide secrets, and break history.
Kind of like creating a Dark Age by burning books and killing
scholars.
At least in openSUSE. No /home, no login, it silently fails (at least in graphical mode).
On Fri, 23 Jan 2026 14:14:55 +0100, Carlos E.R. wrote:
At least in openSUSE. No /home, no login, it silently fails (at least in
graphical mode).
So use a text console.
Weren’t you trying to claim at one point that text console logins wouldn’t
work, while GUI ones would?
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 Fri, 23 Jan 2026 18:38:02 +0800, Mr. Man-wai Chang wrote:
Changing syntax and names can also hide secrets, and break history.
Kind of like creating a Dark Age by burning books and killing
scholars.
That doesn’t work in the age of version control.
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
On 24/1/2026 4:56 am, Lawrence D’Oliveiro wrote:
On Fri, 23 Jan 2026 18:38:02 +0800, Mr. Man-wai Chang wrote:
Changing syntax and names can also hide secrets, and break
history. Kind of like creating a Dark Age by burning books and
killing scholars.
That doesn’t work in the age of version control.
Until there is a sudden unexplained disk crash? :)
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: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,096 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 400:37:26 |
| Calls: | 14,036 |
| Calls today: | 2 |
| Files: | 187,082 |
| D/L today: |
2,901 files (1,741M bytes) |
| Messages: | 2,479,122 |