Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Thu 02 Mar 2023 at 10:32:41 (+0100), daven...@tuxfamily.org wrote:
> On 2023-03-02 00:24, David Wright wrote:
> > On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:
> > > On 2023-02-28 05:27, David Wright wrote:
> > > > On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > > > > On 2023-02-23 02:59, cono...@panix.com wrote:
> >  [ … ]
> > 
> > Well, it looks like cruft from an earlier installation of networking;
> > and a couple of months later, you installed ifupdown and wpasupplicant,
> > by the looks of things. I don't know whether /etc/network/interfaces
> > itself would interfere with however connman is configured.
> > 
> 
> This system never had any debian 10 or lower. It has been issued to my
> by $worksplace
> in december 2021, initially running windows.
> 
> I erased the full disk and installed à "default" (official image)
> debian 11, from an LXDE live USB image

I know nothing about LXDE (or other DEs).

> It has never had any interface named eth0. I still fail to see why
> setup conf would refer to eth0 at all

Some clues are the setup's contents, other files on the system with
contemporaneous timestamps, /var/log/installer/syslog's contents, and so on.

> Then I few month later, I finally took the time to debug why WiFi card
> didn't work/what firmware is needed
> Debian's firmware packaged started supporting the WLAN/WiFi card
> after I installed my system.
> 
> So then I installed the firmware. I most likely installed wpasuppicant
> the same day, and tested it worked.
> 
> Not sure about ifup thought. Doesn't seem to be a wpasupplicant
> dependency.
> 
> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p   netscript-2.4 Provides ifupdown
> p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> p   bridge-utils  Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p   netscript-2.4 Provides ifupdown

This suggests that you or the installer installed ifupdown, and that
it's a top-level package. I would have expected a response more like:

  $ aptitude why apt-file
  Manually installed, current version 3.2.2, priority optional
  No dependencies require to install apt-file
  $ 

but I guess the Provides has some influence. Both ifupdown2 and
netscript can be used instead of ifupdown, though the latter is
for a more specialised scenario.

It's always possible that ifupdown was installed as an alternative
to connman, which is also in the Live image. I don't know which gets
started by default, either in Live, or the subsequent installation
from Live.

> Why openresolv wouldn't work?

That doesn't parse, and without any context, I don't know what it means.

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Thu, Mar 02, 2023 at 12:14:14PM -0600, David Wright wrote:
> On Thu 02 Mar 2023 at 17:23:23 (-), Curt wrote:
> > On 2023-03-02, David  wrote:

[...]

> > Those seem like antithetical concepts.
> 
> The state is identical in both cases, hence using the same letter.
> OTOH the paths to that state can be different, and that's significant
> because installing and then purging a package can have side-effects
> on the system that don't get reverted to the inital state, eg the
> installation of Depends/Recommends.

Heh, you stole my thoughts. I was going "hm, the node in the state
diagram is the same, just the edges are different" :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Thu 02 Mar 2023 at 17:23:23 (-), Curt wrote:
> On 2023-03-02, David  wrote:
> > On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:
> >
> >> Man, I really wish the aptitude(8) man page would explain how to read
> >> the output of "why".  What does the "p" mean?  Purged?  There's nothing
> >> in the man page that explains the symbols in the first 3 columns, as
> >> far as I can find.

It's easy to miss, because the key to the letters is given in running
text a hundred lines away. (man chmod is a loathsome example of this
format.) The reference below is much better, as the figure is a table
(as well as being comprehensive).

> > Yeah. It does mean purged, or never installed.
> >
> >p - the package and all its configuration files were removed, or the
> >package was never installed.
> 
> Those seem like antithetical concepts.

The state is identical in both cases, hence using the same letter.
OTOH the paths to that state can be different, and that's significant
because installing and then purging a package can have side-effects
on the system that don't get reverted to the inital state, eg the
installation of Depends/Recommends.

> >>From here (Buster):
> >   grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

and bullseye.

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Curt]

On 2023-03-02, David  wrote:
> On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:
>
>> Man, I really wish the aptitude(8) man page would explain how to read
>> the output of "why".  What does the "p" mean?  Purged?  There's nothing
>> in the man page that explains the symbols in the first 3 columns, as
>> far as I can find.
>
> Yeah. It does mean purged, or never installed.
>
>p - the package and all its configuration files were removed, or the
>package was never installed.

Those seem like antithetical concepts.

>>From here (Buster):
>   grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README
>
>


-- 

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David]

On Fri, 3 Mar 2023 at 02:18,  wrote:
> On 2023-03-02 14:19, Greg Wooledge wrote:
> > On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:

> >> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> >> > > > p   netscript-2.4 Provides ifupdown
> >> > > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> >> > > > p   bridge-utils  Suggests ifupdown
> >> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> >> > > > p   netscript-2.4 Provides ifupdown
> >
> >> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
> >>
> >> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> >> netscript-2.4 at all

You could try 'aptitude -v why' to add verbosity.

/usr/share/aptitude/README has some discussion about
the behaviour of 'why' and 'why-not'. Under the heading
'why, why-not'.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-03-02 14:19, Greg Wooledge wrote:

On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:


> > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> > > p   netscript-2.4 Provides ifupdown
> > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> > > p   bridge-utils  Suggests ifupdown
> > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> > > p   netscript-2.4 Provides ifupdown



dpkg -l netscript-2.4 or even dpkg -l | grep netscript

Don't return anything… Not sure why "aptitude why ifupdown" mentions
netscript-2.4 at all


Oh, that's reassuring.  And also confusing.

Man, I really wish the aptitude(8) man page would explain how to read
the output of "why".  What does the "p" mean?  Purged?  There's nothing
in the man page that explains the symbols in the first 3 columns, as
far as I can find.


I wonder if aptitude just uses the dpkg-query abbreviations,
so "purged" seems a reasonable guess. But yeah, it would be
much more helpful if aptitude(8) man was not that ambiguous
about those abbreviations



I have *no* idea how to interpret this:

unicorn:~$ aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
unicorn:~$ dpkg -l ifupdown | tail -n1
ii  ifupdown   0.8.36   amd64high level tools to
configure network interfaces

Maybe "aptitude why" simply can't handle packages that are part of
the base system ("Essential", or priority "required" or "important"),
or which have been manually installed and aren't part of a 
dependency...?


unicorn:~$ aptitude why bash
i   bash-builtins Depends bash (= 5.1-2+deb11u1)
unicorn:~$ aptitude why dpkg
i   google-chrome-stable PreDepends dpkg (>= 1.14.0)
unicorn:~$ aptitude why abcde
Manually installed, current version 2.9.3-1, priority optional
No dependencies require to install abcde

OK, I guess it handles manually installed packages.  But not base
system packages... at least not in a way one would expect.

In any case, ifupdown is an "important" package, and should be present
on almost all Debian systems, regardless of what "aptitude why" says
about it.

unicorn:~$ dpkg -s ifupdown | grep Prio
Priority: important


Good to know. I'd except it to be installed by default by the way. 
Looking again at files in /etc/network, there are


drwxr-xr-x 2 root root 4096  2 déc.   2021 if-post-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-pre-up.d

The laptop was installed on the 2nd December 2021, so the files existed 
from day one,

But if-down.d and if-up.d content was updated later.
Must by the reason why someone (don't remember their name) on this 
thread suggested I have installed

ifupdown a few months laters.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David]

On Fri, 3 Mar 2023 at 00:19, Greg Wooledge  wrote:

> Man, I really wish the aptitude(8) man page would explain how to read
> the output of "why".  What does the "p" mean?  Purged?  There's nothing
> in the man page that explains the symbols in the first 3 columns, as
> far as I can find.

Yeah. It does mean purged, or never installed.

   p - the package and all its configuration files were removed, or the
   package was never installed.

>From here (Buster):
  grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Thu, Mar 02, 2023 at 02:01:57PM +0100, daven...@tuxfamily.org wrote:

> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> > > > p   netscript-2.4 Provides ifupdown
> > > > p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> > > > p   bridge-utils  Suggests ifupdown
> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> > > > p   netscript-2.4 Provides ifupdown

> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
> 
> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> netscript-2.4 at all

Oh, that's reassuring.  And also confusing.

Man, I really wish the aptitude(8) man page would explain how to read
the output of "why".  What does the "p" mean?  Purged?  There's nothing
in the man page that explains the symbols in the first 3 columns, as
far as I can find.

I have *no* idea how to interpret this:

unicorn:~$ aptitude why ifupdown
p   netscript-2.4 Provides ifupdown   
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown   
unicorn:~$ dpkg -l ifupdown | tail -n1
ii  ifupdown   0.8.36   amd64high level tools to configure 
network interfaces

Maybe "aptitude why" simply can't handle packages that are part of
the base system ("Essential", or priority "required" or "important"),
or which have been manually installed and aren't part of a dependency...?

unicorn:~$ aptitude why bash
i   bash-builtins Depends bash (= 5.1-2+deb11u1)
unicorn:~$ aptitude why dpkg
i   google-chrome-stable PreDepends dpkg (>= 1.14.0)
unicorn:~$ aptitude why abcde
Manually installed, current version 2.9.3-1, priority optional
No dependencies require to install abcde

OK, I guess it handles manually installed packages.  But not base
system packages... at least not in a way one would expect.

In any case, ifupdown is an "important" package, and should be present
on almost all Debian systems, regardless of what "aptitude why" says
about it.

unicorn:~$ dpkg -s ifupdown | grep Prio
Priority: important

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-03-02 13:47, daven...@tuxfamily.org wrote:

On 2023-03-02 13:32, Greg Wooledge wrote:
On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org 
wrote:
This system never had any debian 10 or lower. It has been issued to 
my by

$worksplace
in december 2021, initially running windows.



akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown


unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network 
config system.
 This is a router and firewall network configuration system.  It is 
specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, 
even

 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual 
Machine
 server with complex networking needs.  This is because of its 
comprehensive
 network configuration capabilities.  Thus it is a tempting 
replacement

 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.


Obviously NOT those old kernels. I'm runnning kernel 5.10

~$ uname -r
5.10.0-21-amd64

Why is this paquet installed at all then?


dpkg -l netscript-2.4 or even dpkg -l | grep netscript

Don't return anything… Not sure why "aptitude why ifupdown" mentions 
netscript-2.4 at all

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-03-02 13:32, Greg Wooledge wrote:

On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org wrote:
This system never had any debian 10 or lower. It has been issued to my 
by

$worksplace
in december 2021, initially running windows.



akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown


unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network 
config system.
 This is a router and firewall network configuration system.  It is 
specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, 
even

 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual 
Machine
 server with complex networking needs.  This is because of its 
comprehensive

 network configuration capabilities.  Thus it is a tempting replacement
 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.


Obviously NOT those old kernels. I'm runnning kernel 5.10

~$ uname -r
5.10.0-21-amd64

Why is this paquet installed at all then?

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Thu, Mar 02, 2023 at 10:32:41AM +0100, daven...@tuxfamily.org wrote:
> This system never had any debian 10 or lower. It has been issued to my by
> $worksplace
> in december 2021, initially running windows.

> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p   netscript-2.4 Provides ifupdown
> p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
> p   bridge-utils  Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p   netscript-2.4 Provides ifupdown

unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network config system.
 This is a router and firewall network configuration system.  It is specific to
 the 2.4.x and 2.6.x kernel series. This system is in production use, even
 though this is an experimental version.
[...]
 DON'T use this on a pure server - it is VERY useful for a Virtual Machine
 server with complex networking needs.  This is because of its comprehensive
 network configuration capabilities.  Thus it is a tempting replacement
 when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me.  I'm surprised it works *at all*
with a Debian 11 (or higher?  you didn't say what you *are* running,
only what you're *not* running) kernel.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-03-02 00:24, David Wright wrote:

On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:

On 2023-02-28 05:27, David Wright wrote:
> On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > On 2023-02-23 02:59, cono...@panix.com wrote:

 [ … ]

Well, it looks like cruft from an earlier installation of networking;
and a couple of months later, you installed ifupdown and wpasupplicant,
by the looks of things. I don't know whether /etc/network/interfaces
itself would interfere with however connman is configured.



This system never had any debian 10 or lower. It has been issued to my 
by $worksplace

in december 2021, initially running windows.

I erased the full disk and installed à "default" (official image) debian 
11, from an LXDE live USB image
It has never had any interface named eth0. I still fail to see why setup 
conf would refer to eth0 at all


Then I few month later, I finally took the time to debug why WiFi card 
didn't work/what firmware is needed
Debian's firmware packaged started supporting the WLAN/WiFi card 
after I installed my system.


So then I installed the firmware. I most likely installed wpasuppicant 
the same day, and tested it worked.


Not sure about ifup thought. Doesn't seem to be a wpasupplicant 
dependency.


akb@akira:~$ LC_ALL=C aptitude why ifupdown
p   netscript-2.4 Provides ifupdown
p   netscript-2.4 Depends  bridge-utils (>= 0.9.3)
p   bridge-utils  Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p   netscript-2.4 Provides ifupdown

Why openresolv wouldn't work?



Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Tue 28 Feb 2023 at 16:05:14 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-28 05:27, David Wright wrote:
> > On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> > > On 2023-02-23 02:59, cono...@panix.com wrote:
> > > 
> > > […]
> > > 
> > > On the newer work laptop on the other hand, there is that eth0 block,
> > > there's is no eth0 interface on my system (there's enp.* and enx.*
> > > systemd names, instead)
> > > BUT I never had the slow/timeout-waiting boot process unlike the
> > > personal was reinstall from zero instead of upgraded years ago only to
> > > change HDD to SSD, and to change partitioning to encrypted LVM.
> > 
> > What are these enp… (waste of time hiding that name) and enx…
> > interfaces (and any others), and what are they used for.
> > 
> 
> It's the systemd-style so-called "predictable" interfaces names.
> Replacing the older the eth0, wlan0, and so on…
> 
> ens-something (annoying name made of multiple letters and digits) is
> the new name for eth0
> wlx-something or wlp-something for wlan0
> enx-insert-long-hexadecimal-number-here is well… I have no damn idea.
> 
> Seen this last one only my work's computer, not personal one. Much
> newer, maybe have some optional network hardware?
> Not sure, but it's not virtual interface for the VPN. which is still
> named tun0 as it used to be before systemd.
> And the unknown interface is still around even without the VPN process
> running
> 
> And it's not really hiding. it's just a name I can never fully remember
> and didn't bother to check full name. It doesn't really matter.
> What matters is the interface is not called eth0 anymore, but is
> instead called ens-whatever-thefullname-is. And the interface name
> used in
> /etc/network/interfaces.d/setup refers to a network interface which
> doen't exist anymore
> 
> Yet it does NOT break the network, that why I think something else
> replaced.
> Otherwise, I fail to see how it would work while referencing to the
> wrong interface name.
> 
> (Also, the new name for wlan0 interface is "wlx" followed by an UID
> *on some* systems. not all
> So it actually does make sense to hide it, for such systems)

Yes, sorry, I won't bother with understanding what interfaces are
present on which systems, and which ones are used for what, when.
(If you reread my question above, you'll see that I didn't ask you
to reveal the MAC address of your wifi, BTW.)

> > > So my guess is /etc/network/interface.* has been replaced with
> > > something also. Since it refers to non-exitent interfaces names
> > > without breaking the network or slowing down the boot process.
> > > 
> > > Also, the switching to systemd styles interfaces names has been
> > > following by a weird behaviour on my personal computer. It has a
> > > "failed" error message at startup, for the network (or is networking?
> > > it never remember the correct name) service, without breaking the
> > > network… it weirdly just works. I never figured out what replaces that
> > > service. If anyone has any idea?
> > 
> > Different installation scripts and/or individual sysadmins can place
> > files with a variety of names in /etc/network/interface.d/. So their
> > removal can be rather sporadic: Debian won't know their names, and
> > deinstallation scripts might leave them, if they get run at all.
> > 
> > It's worrying that such files are there if they have the wrong
> > interface names in them. It might suggest ancient cruft or, just
> > as easily, network installation scripts that are broken, or designed
> > for a different system/distribution.
> > 
> > What's the output from   ls -lR /etc/network* /etc/systemd/network*
> 
> Here's the output.
> 
 [ … ]
> 
> Not sue if it contains anything DHCP client related
> Beside the /etc/network/interfaces.d/setup which contains only local
> interface and eth0

Well, it looks like cruft from an earlier installation of networking;
and a couple of months later, you installed ifupdown and wpasupplicant,
by the looks of things. I don't know whether /etc/network/interfaces
itself would interfere with however connman is configured.

> But again. I don't to fully stop using DHCP, which is would be the
> most obvious thing I could do on the setup file if it were used.
> 
> I just don't want the DHCP client send requests to my home's network
> instead of sending requests through the VPN route
> so the workplace's DHCP sees and answers to the requests, instead of
> home router answering to these requests
> 
> I fail to see why the DHCP client would send it requests to
> 192.168.1.1 (my home's gateway) instead of using the VPN
> interface/route/whatever.
> dhclient must have some wrong conf, but I never changed the default
> conf, So I have no idea what part may be wrong or what's missing

I had thought that it might be possible to configure a package like
openresolv to manage the contention between the configurations, but
judging what I've learned about your networking setup, it's probably
easie

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Tixy]

On Tue, 2023-02-28 at 16:05 +0100, daven...@tuxfamily.org wrote:
> 
> It's the systemd-style so-called "predictable" interfaces names.
> Replacing the older the eth0, wlan0, and so on…
> 
> ens-something (annoying name made of multiple letters and digits) is the 
> new name for eth0

Or eno for ethernet too. My ethernet started out as eno2 when I
did the initial install and this changed to eno1 when I disabled the
onboard wireless in the bios.

-- 
Tixy 

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-02-28 05:27, David Wright wrote:

On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:

On 2023-02-23 02:59, cono...@panix.com wrote:

[…]

On the newer work laptop on the other hand, there is that eth0 block,
there's is no eth0 interface on my system (there's enp.* and enx.*
systemd names, instead)
BUT I never had the slow/timeout-waiting boot process unlike the
personal was reinstall from zero instead of upgraded years ago only to
change HDD to SSD, and to change partitioning to encrypted LVM.


What are these enp… (waste of time hiding that name) and enx…
interfaces (and any others), and what are they used for.



It's the systemd-style so-called "predictable" interfaces names.
Replacing the older the eth0, wlan0, and so on…

ens-something (annoying name made of multiple letters and digits) is the 
new name for eth0

wlx-something or wlp-something for wlan0
enx-insert-long-hexadecimal-number-here is well… I have no damn idea.

Seen this last one only my work's computer, not personal one. Much 
newer, maybe have some optional network hardware?
Not sure, but it's not virtual interface for the VPN. which is still 
named tun0 as it used to be before systemd.
And the unknown interface is still around even without the VPN process 
running


And it's not really hiding. it's just a name I can never fully remember
and didn't bother to check full name. It doesn't really matter.
What matters is the interface is not called eth0 anymore, but is
instead called ens-whatever-thefullname-is. And the interface name used 
in
/etc/network/interfaces.d/setup refers to a network interface which 
doen't exist anymore


Yet it does NOT break the network, that why I think something else 
replaced.
Otherwise, I fail to see how it would work while referencing to the 
wrong interface name.


(Also, the new name for wlan0 interface is "wlx" followed by an UID *on 
some* systems. not all

So it actually does make sense to hide it, for such systems)


So my guess is /etc/network/interface.* has been replaced with
something also. Since it refers to non-exitent interfaces names
without breaking the network or slowing down the boot process.

Also, the switching to systemd styles interfaces names has been
following by a weird behaviour on my personal computer. It has a
"failed" error message at startup, for the network (or is networking?
it never remember the correct name) service, without breaking the
network… it weirdly just works. I never figured out what replaces that
service. If anyone has any idea?


Different installation scripts and/or individual sysadmins can place
files with a variety of names in /etc/network/interface.d/. So their
removal can be rather sporadic: Debian won't know their names, and
deinstallation scripts might leave them, if they get run at all.

It's worrying that such files are there if they have the wrong
interface names in them. It might suggest ancient cruft or, just
as easily, network installation scripts that are broken, or designed
for a different system/distribution.

What's the output from   ls -lR /etc/network* /etc/systemd/network*


Here's the output.

---

ls -lR /etc/network* /etc/systemd/network*
-rw-r--r-- 1 root root   60  9 oct.   2021 /etc/networks
-rw-r--r-- 1 root root  609  2 févr.  2021 /etc/systemd/networkd.conf

/etc/network:
total 24
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-post-down.d
drwxr-xr-x 2 root root 4096  2 déc.   2021 if-pre-up.d
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-up.d
-rw-r--r-- 1 root root  321  2 déc.   2021 interfaces
drwxr-xr-x 2 root root 4096  2 déc.   2021 interfaces.d

/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015  6 févr.  2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv.  2022 clamav-freshclam-ifupdown
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1409  7 mars   2020 wireless-tools
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root  344 30 juin   2016 ethtool
-rwxr-xr-x 1 root root 4191  7 mars   2020 wireless-tools
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root  923  6 févr.  2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv.  2022 clamav-freshclam-ifupdown
-rwxr-xr-x 1 root root 1685 30 juin   2016 ethtool
lrwxrwxrwx 1 root root   32  2 déc.   2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


/etc/network/interfaces.d:
total 4
-rw-r--r-- 1 root root 63  9 oct.   2021 setup

/etc/systemd/network:
total 0

---

Not sue if it contains anything DHCP client related
Beside the /etc/network/interfaces.d/setup which contains only local 
interface and eth0
But again. I don't to fully stop using DHCP, which is would be the most 
obvious 

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Thu 23 Feb 2023 at 11:23:30 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-23 02:59, cono...@panix.com wrote:
> > On 2/22/23, daven...@tuxfamily.org  wrote:
> > > 
> > > There is an unidentified process that decides it's ok to delete and
> > > recreate /etc/resolv.conf without asking user/admin,
> > > The problem is, the problematic process is not work's VPN related and
> > > creates the file with wrong resolver's IP. The IP corresponds
> > > to my home
> > > router IP, which does has a DNS resolver and it works as it
> > > should. BUT
> > > my home's router DNS obviously don't know jack about work internal
> > > servers, on which I work… and work's proxy as well, which
> > > when it cannot
> > > be resolved… breaks everything using HTTP.
> > 
> > Might look at:
> > 
> > /etc/network/interfaces.d/setup
> > 
> > as explained in "man interfaces". (That file can/might be changed via
> > the network symbol in the window manager's configuration bar/menu
> > system, usually required with root/sudo privileges.)
> 
> There's nothing relevant to change in that file. I don't want to have
> static IP. And the right interface name is not in it.
> 
> I'm not sure whether that file became totally obsoleled, or if it's
> not normal that it doesn't contain the expected interface name? has it
> been deprecated since debian switched to systemd so-called
> "predictable" iface names?
> 
> For some reasons, since debian 9 or 10 (id nor 8?), including debian
> 11 new installs (work laptop has been install slightly more than a
> year ago),
> that files only contains the eth0 and local interfaces name, while
> debian switched to systemd style interfaces names.
> I remembrer having slowed down boots because of the that, on my
> personal laptop, when debian switched to systemd style names and that
> file still referred to eth0 which doesn't exist
> So boot process was waiting for eth0 interface until I commented out
> that part (eth0 block) of interfaces files.
> 
> On the newer work laptop on the other hand, there is that eth0 block,
> there's is no eth0 interface on my system (there's enp.* and enx.*
> systemd names, instead)
> BUT I never had the slow/timeout-waiting boot process unlike the
> personal was reinstall from zero instead of upgraded years ago only to
> change HDD to SSD, and to change partitioning to encrypted LVM.

What are these enp… (waste of time hiding that name) and enx…
interfaces (and any others), and what are they used for.

> So my guess is /etc/network/interface.* has been replaced with
> something also. Since it refers to non-exitent interfaces names
> without breaking the network or slowing down the boot process.
> 
> Also, the switching to systemd styles interfaces names has been
> following by a weird behaviour on my personal computer. It has a
> "failed" error message at startup, for the network (or is networking?
> it never remember the correct name) service, without breaking the
> network… it weirdly just works. I never figured out what replaces that
> service. If anyone has any idea?

Different installation scripts and/or individual sysadmins can place
files with a variety of names in /etc/network/interface.d/. So their
removal can be rather sporadic: Debian won't know their names, and
deinstallation scripts might leave them, if they get run at all.

It's worrying that such files are there if they have the wrong
interface names in them. It might suggest ancient cruft or, just
as easily, network installation scripts that are broken, or designed
for a different system/distribution.

What's the output from   ls -lR /etc/network* /etc/systemd/network*

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Mon, Feb 27, 2023 at 03:14:40PM +0100, daven...@tuxfamily.org wrote:
> I did
> 
> - chattr +i /etc/revolv.conf
> 
> And when auditd showed a (failed) delete event on /etc/resolv.conf
> 
> I grepped "resolv.conf" recursively on /var/log/, and All I've found are
> entries in
> 
> - /var/log/installer from more than 1 year ago, since the log file is small,
> I guess it has never been rotated
> - audit.log, since write and append  to "/etc/resolv.conf" are audited
> - auth.log : authentication related to commands I've used this morning,
> which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i
> /etc/revolv.conf"
> 
> But whatever process tried to delete "/etc/resolv.conf" whidle it was
> immutable, didn't leave traces.
> Not even a log for permission error because of the immutable flag. At least
> not in /var/log anyway.

I can't say I'm shocked.  But you *did* find an entry from auditd, which
presumably has a timestamp.  Check to see what was happening right at
that moment in other log files.

In particular, check whether a DHCP client daemon renewed its DHCP lease
at that time.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello

On 2023-02-24 11:27, daven...@tuxfamily.org wrote:

On 2023-02-24 10:27, to...@tuxteam.de wrote:
On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org 
wrote:


[...]

BUT I will make sure to take some time to dig into the logs monday.
Now that I have an idea what I'm looking for, totally agree logs are
better than suspicion


I did

- chattr +i /etc/revolv.conf

And when auditd showed a (failed) delete event on /etc/resolv.conf

I grepped "resolv.conf" recursively on /var/log/, and All I've found are 
entries in


- /var/log/installer from more than 1 year ago, since the log file is 
small, I guess it has never been rotated

- audit.log, since write and append  to "/etc/resolv.conf" are audited
- auth.log : authentication related to commands I've used this morning, 
which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i 
/etc/revolv.conf"


But whatever process tried to delete "/etc/resolv.conf" whidle it was 
immutable, didn't leave traces.
Not even a log for permission error because of the immutable flag. At 
least not in /var/log anyway.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Fri 24 Feb 2023 at 10:19:38 (+0100), daven...@tuxfamily.org wrote:
> > […]
> > vpnc_script has about eight methods available for setting up and
> > reverting resolv.conf. Which is used depends on the presence of
> > a binary, checked in turn from this list:
> > 
> >   /etc/openwrt_release  modify_resolvconf_openwrt
> >   /usr/bin/resolvectl   modify_resolved_manager
> >   /usr/bin/busctl   modify_resolved_manager_old
> >   /sbin/resolvconf  modify_resolvconf_manager
> >   /sbin/netconfig   modify_resolvconf_suse_netconfig
> >   /sbin/modify_resolvconf   modify_resolvconf_suse
> >   /usr/sbin/unbound-control modify_resolvconf_unbound
> >   otherwise modify_resolvconf_generic
> > 
> > Perhaps you could check which of those binaries you have.
> 
> I have they two resolved_manager binaries, but since systemd-resolvd
> service is disabled and stopped on my system, I highly doubt these are
> used.
> It's more likely modify_resolvconf_generic
> 
> However, I didn't notice any vnpc_script malfunction. It does what it
> is expected to do. I'm like 99% sure the problem is dhclient deleting
> and recreating /etc/resolv.conf as it sees fit, multiple times a day,
> and deleting whatever vpnc_script has put in that file.

If that's the case, then unfortunately the vnpc_script gives you no
protection against that happening. All it appears to do, when you
connect, is to write:

  #@VPNC_GENERATED@ -- this file is generated by vpnc
  # and will be overwritten by vpnc
  # as long as the above mark is intact"

at the start of resolv.conf, so that when you disconnect, it can check
if that first string is still there and, if it is, restore the previous
contents of the file.

Meanwhile, anything else might overwrite the file, and if it does,
it's likely that the vnpc_script won't even be able to restore the
previous version of the file when you disconnect.

You'll notice that none of the other functions actually reference
resolv.conf itself, but will store the real file elsewhere, and
publish it through a symlink.

> > > > But how do you manage /etc/resolv.conf with connman. I don't use it,
> > 
> > Actually I was interested in what sets up your ordinary networking,
> > the one that uses your ISP, when you're not "at work" …
> 
> - ConnMan is used to manually connect to/disconnect from wired, and
> much less often wireless (wifi, bluetooth) networks
> - dhclient is used for DHCP request

They should work with either of the resolvconf packages that Debian
supplies, resolvconf and openresolv. I use the latter, as iwd documents
that it supports it. I know there are people on this list who use connman.

> - My OpenWRT router with DHCP is used as gateway for my subnet,
> answers to DHCP requests

I do much the same, with my router (two, actually) connected to the
ISP's ethernet connector.

> - Then there's is toward my ISP's all-in-one router/modem + TV set top
> box + telephony bullshit (I don't use anything but Interne, but ISP
> enforces their "triple play bullshit so I have to do with that all in
> one device… There's no alternatives for DOCSIS, Since I can't get FTTH
> yet, which my current router doesn't support yet, either way I'm
> dependant on ISP router)

Everything of ours runs from my router, so the ISP's is just a
glorified modem.

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:
> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Then use one of the methods listed at <https://wiki.debian.org/resolv.conf>
to address that, and see if it fixes the problem.

The simplest one to test would be
<https://wiki.debian.org/resolv.conf#Configuring_dhclient>.  It doesn't
involve installing any new packages.

If your testing is successful (e.g. a whole day goes by and the
resolv.conf file is not unexpectedly altered), then things get a little
bit trickier.  If I understand correctly, you're working on a laptop,
and your desired configuration is:

 * At boot time, allow the DHCP client to set up resolv.conf.

 * Once that has been done, disallow all further modifications of
   resolv.conf by the DHCP client.

 * Allow modifications of resolv.conf by vpnc_script at any time.

The tricky part here is how to write a function that determines whether
dhclient should be allowed to modify the file ("is it boot time") or not.
Perhaps you could use something awful like "if the system uptime is less
than 5 minutes, allow it".

Another hack that comes to mind would be writing something that removes
the resolv.conf file at shutdown time.  Then, the dhclient hook function
would allow dhclient to write the file if and only if it doesn't exist.

Or... the reverse of this.  Keep a second file which serves as a flag
indicating that the resolv.conf file has already been configured once.
Remove this flag at boot time (make sure that happens *early*, before
dhclient is started), and then write your dhclient hook function to
allow the modification if and only if the flag file doesn't exist.  Then
create the flag file after doing the modification.

I'm not sure which of those is the least bad.  Maybe you can come up
with some other ideas.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Fri, Feb 24, 2023 at 11:27:40AM +0100, daven...@tuxfamily.org wrote:

> [...] totally agree logs are better than suspicion

But please, don't take my snark all too seriously. On reread I
realize it might have sounded harsher than it was meant.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-02-24 10:27, to...@tuxteam.de wrote:

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

However, I didn't notice any vnpc_script malfunction. It does what it 
is

expected to do. I'm like 99% sure the problem is dhclient deleting and
recreating /etc/resolv.conf as it sees fit, multiple times a day, and
deleting whatever vpnc_script has put in that file.


Instead of 99% suspicions you could just look into your 
/var/log/syslog:

dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers


Goode point. Thank you for the reminder :)

I do only partial week remote work, been in the office the last days.
So in order for the problem to happen again, I need to wait monday, only 
then I might dig into the log files.


The thing is: at first, I didn't suspect dhclient until recently (after 
I started this thread) so I need to wait for the next remote work day.
During my last days of remote work, I just used auditd to see if I can 
see process name when the file is deleted/recreated.
The event was captured by auditd but the process name was missing from 
the audit.log file, so I had no idea what's to look for., in which log 
file(s).


I'm still sure it isn't vpnc_script. vpnc_script leaves identification 
comments on the file
And dhclient is more like to know only about what my home's DHCP tells 
it, than my work's place DNS resolver, that's why I suspect dhclient.
BUT I will make sure to take some time to dig into the logs monday. Now 
that I have an idea what I'm looking for, totally agree logs are better 
than suspicion

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Instead of 99% suspicions you could just look into your /var/log/syslog:
dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello,


[…]
vpnc_script has about eight methods available for setting up and
reverting resolv.conf. Which is used depends on the presence of
a binary, checked in turn from this list:

  /etc/openwrt_release  modify_resolvconf_openwrt
  /usr/bin/resolvectl   modify_resolved_manager
  /usr/bin/busctl   modify_resolved_manager_old
  /sbin/resolvconf  modify_resolvconf_manager
  /sbin/netconfig   modify_resolvconf_suse_netconfig
  /sbin/modify_resolvconf   modify_resolvconf_suse
  /usr/sbin/unbound-control modify_resolvconf_unbound
  otherwise modify_resolvconf_generic

Perhaps you could check which of those binaries you have.



I have they two resolved_manager binaries, but since systemd-resolvd 
service is disabled and stopped on my system, I highly doubt these are 
used.

It's more likely modify_resolvconf_generic

However, I didn't notice any vnpc_script malfunction. It does what it is 
expected to do. I'm like 99% sure the problem is dhclient deleting and 
recreating /etc/resolv.conf as it sees fit, multiple times a day, and 
deleting whatever vpnc_script has put in that file.





> But how do you manage /etc/resolv.conf with connman. I don't use it,


Actually I was interested in what sets up your ordinary networking,
the one that uses your ISP, when you're not "at work" …


- ConnMan is used to manually connect to/disconnect from wired, and much 
less often wireless (wifi, bluetooth) networks

- dhclient is used for DHCP request
- My OpenWRT router with DHCP is used as gateway for my subnet, answers 
to DHCP requests
- Then there's is toward my ISP's all-in-one router/modem + TV set top 
box + telephony bullshit (I don't use anything but Interne, but ISP 
enforces their "triple play bullshit so I have to do with that all in 
one device… There's no alternatives for DOCSIS, Since I can't get FTTH 
yet, which my current router doesn't support yet, either way I'm 
dependant on ISP router)





Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
generated according to my home router's DHCP tells the computer


… yes, that one.

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Thu, Feb 23, 2023 at 11:39:03PM -0600, David Wright wrote:

[...]

> vpnc_script has about eight methods available for setting up and
> reverting resolv.conf. Which is used depends on the presence of
> a binary, checked in turn from this list:
> 
>   /etc/openwrt_release  modify_resolvconf_openwrt
>   /usr/bin/resolvectl   modify_resolved_manager
>   /usr/bin/busctl   modify_resolved_manager_old
>   /sbin/resolvconf  modify_resolvconf_manager
>   /sbin/netconfig   modify_resolvconf_suse_netconfig
>   /sbin/modify_resolvconf   modify_resolvconf_suse
>   /usr/sbin/unbound-control modify_resolvconf_unbound
>   otherwise modify_resolvconf_generic
> 
> Perhaps you could check which of those binaries you have.

Thanks for this one. I think this is the most constructive
contribution to this thread.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Thu 23 Feb 2023 at 10:44:35 (+0100), daven...@tuxfamily.org wrote:
> On 2023-02-22 22:08, David Wright wrote:
> > On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:
> > 
> > > What I want is: setting up /etc/resolv.conf ONLY
> > > -  at system startup/initial network connexion.
> > > - when openconnect is executed and connects to work's VPN
> > > - when openconnect is ^C-ed and disconnects from the works VPN
> > > (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> > > and other netwwork stuff it might have modified, makes sense)
> > 
> > What's the output from   ls -l /etc/resolv.conf
> 
> -rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf
> 
> With the ctime changing more or less often, since it is
> deleted/recreated by what I suspect to do DHCP requests (see
> audit.log)

Being a real file, it's not protected from being modified by any
process that wants to. A resolv.conf manager will set up resolv.conf
as a symlink to a file that it controls, so that it can manage
contention between different processes.

> > What's responsible for restoring the previous contents of
> > /etc/resolv.conf to your normal network connection when you
> > finish "work" and tear down the VPN.
> 
> openconnect does. When it's CTRL-C-ed to disconnect from the workplace
> VPN, resolv.conf is reverted back to my home network resolver
> Not sure whether vpnc_script just calls the DHCP client (probably
> dhclient since it's the only dhcp client preinstalled, at least I'm
> aware of)
[ … ]
> > One way of finding the process is to  # chattr +i /etc/resolv.conf
> > while you're "at work", so that you get permission errors in the
> > logs when it happens. (Remember to chattr -i before you "stop work".)
> 
> Thank you. I'll give it a try, But I won't be on remote work before
> next week
> Which log file is used for that?
> So instead of grepping /var/log/ recursively when the problem occurs.
> I'd tail -f the right file to find the "rogue" process right away

I don't know. I thought the destination was chosen more by the program
than the error type. Perhaps daemon.log and syslog might be good
candidates. Of course, after the event you can check them all.

> openconnect uses something called vpnc_script.
> When openconnects is exc, resolv.conf contains the appropriate info as
> well a comment including "VPNC_GENERATED"
> 
> > but I read there's a plug-in for that. Is openconnect correctly
> > informing connman when it finishes.
> 
> Whether it informs connmann or cleans after itself without involving
> connmann, I don't know and I'm not sure how to check that out.
> I'm not familiar with how vpnc_script works and what it does _exactly_
> But it does clean up the config and network config is left in working
> state when openconnect disconnects

vpnc_script has about eight methods available for setting up and
reverting resolv.conf. Which is used depends on the presence of
a binary, checked in turn from this list:

  /etc/openwrt_release  modify_resolvconf_openwrt
  /usr/bin/resolvectl   modify_resolved_manager
  /usr/bin/busctl   modify_resolved_manager_old
  /sbin/resolvconf  modify_resolvconf_manager
  /sbin/netconfig   modify_resolvconf_suse_netconfig
  /sbin/modify_resolvconf   modify_resolvconf_suse
  /usr/sbin/unbound-control modify_resolvconf_unbound
  otherwise modify_resolvconf_generic

Perhaps you could check which of those binaries you have.

> > But how do you manage /etc/resolv.conf with connman. I don't use it,

Actually I was interested in what sets up your ordinary networking,
the one that uses your ISP, when you're not "at work" …

> Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
> generated according to my home router's DHCP tells the computer

… yes, that one.

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Reco]

Hi.

On Thu, Feb 23, 2023 at 11:31:44AM +0100, daven...@tuxfamily.org wrote:
> > If it is DHCP: You might do a countermeasure in
> > /etc/dhcp/dhclient.conf. On my system I have an entry as below.
> > 
> > interface "wlp4s0" {
> > supersede domain-name-servers 127.0.0.1;
> 
> Unfortunately, I can't use supersede parameter because I need to use
> different resolvers at different times/in different contexts.
> 
> I would need something more… conditional
> 
> IF openconnect is running and has modified resolv.conf, leave that
> file alone unless you are openconnect Otherwise, when there's no VPN
> active, you can do normal DHCP requests and accept whatever
> currently-active network's router/DHCP tells you and update resolve
> conf accordingly

openconnect has that helpful --script option, which calls
/usr/share/vpnc-scripts/vpnc-script by default.
All you need is to make a copy of that script, modify dhclient.conf
at "connect" and "disconnect" phases accordingly, and then call your
modified script from openconnect.

Reco

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-02-23 10:54, to...@tuxteam.de wrote:

On Thu, Feb 23, 2023 at 10:44:35AM +0100, daven...@tuxfamily.org wrote:

[...]

Thank you. I'll give it a try, But I won't be on remote work before 
next

week
Which log file is used for that?


That depends: it's the perpetrator's choice where to log (or whether
to log at all, sadly).

So instead of grepping /var/log/ recursively when the problem occurs. 
I'd

tail -f the right file to find the "rogue" process right away


You know that you can tail -f more than one file, do you?

I just learnt that from a colleague. Enormously handy.

Cheers


Interesting! I didn't knew that. Thanks for the tip.

I knew about and I just remembered multitail, which I never used that 
much, cause can be too noisy… But I guess I'm going to use "grep 
resolv.conf"… But if the "rogue" process doesn't log anything… I'll be 
stuck… worth trying either way. Thanks

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Jeremy Ardley]

On 23/2/23 18:23, daven...@tuxfamily.org wrote:

Hello,

On 2023-02-23 02:59, cono...@panix.com wrote:

On 2/22/23, daven...@tuxfamily.org  wrote:


There is an unidentified process that decides it's ok to delete and
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and
creates the file with wrong resolver's IP. The IP corresponds to my 
home

router IP, which does has a DNS resolver and it works as it should. BUT
my home's router DNS obviously don't know jack about work internal
servers, on which I work… and work's proxy as well, which when it 
cannot

be resolved… breaks everything using HTTP.


Might look at:

    /etc/network/interfaces.d/setup

as explained in "man interfaces". (That file can/might be changed via
the network symbol in the window manager's configuration bar/menu
system, usually required with root/sudo privileges.)

    John


There's nothing relevant to change in that file. I don't want to have 
static IP. And the right interface name is not in it.


I'm not sure whether that file became totally obsoleled, or if it's 
not normal that it doesn't contain the expected interface name? has it 
been deprecated since debian switched to systemd so-called 
"predictable" iface names?


For some reasons, since debian 9 or 10 (id nor 8?), including debian 
11 new installs (work laptop has been install slightly more than a 
year ago),
that files only contains the eth0 and local interfaces name, while 
debian switched to systemd style interfaces names.
I remembrer having slowed down boots because of the that, on my 
personal laptop, when debian switched to systemd style names and that 
file still referred to eth0 which doesn't exist
So boot process was waiting for eth0 interface until I commented out 
that part (eth0 block) of interfaces files.


On the newer work laptop on the other hand, there is that eth0 block, 
there's is no eth0 interface on my system (there's enp.* and enx.* 
systemd names, instead)
BUT I never had the slow/timeout-waiting boot process unlike the 
personal was reinstall from zero instead of upgraded years ago only to 
change HDD to SSD, and to change partitioning to encrypted LVM.


So my guess is /etc/network/interface.* has been replaced with 
something also. Since it refers to non-exitent interfaces names 
without breaking the network or slowing down the boot process.


Also, the switching to systemd styles interfaces names has been 
following by a weird behaviour on my personal computer. It has a 
"failed" error message at startup, for the network (or is networking? 
it never remember the correct name) service, without breaking the 
network… it weirdly just works. I never figured out what replaces that 
service. If anyone has any idea?


As a general comment on resolving name service problems you need to 
become acquainted with nsswitch


I have only recently become aware of it. It's central in determining 
just how your system looks up lots of things including DNS names.


Some research and reading is required (for me and perhaps most?)

--
Jeremy
(Lists)

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hi

On 2023-02-22 18:30, Christoph Brinkhaus wrote:
Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb 
daven...@tuxfamily.org:


= context =
For the context, I use a Debian 11 laptop for work. When I work 
remotely
from home, I have to use a cisco VPN. Good thing is there is 
openconnect,
which does work, and in teh case of ym work's VPN, it does wor. 
cisco's

spyware/downloaded binry, namely using the --csd-wrapper
/usr/libexec/openconnect/"

[snip]

= end of context =
What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN 
(cleaning
it's mess in the routing table, interfaces, /etc/resolv's and other 
netwwork

stuff it might have modified, makes sense)

Here's what I know:
- Whatever process does that seems does what I highly suspect to be 
DHCP [1]
requests every now and then. Home's router answers giving it's own 
address
as both gateway and DNS resolver. And said process thinks it's OK to 
delete
and recreate resolv.conf with the wrong content… breaking everything 
work's

related while the VPN is still active


If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;


Unfortunately, I can't use supersede parameter because I need to use 
different resolvers at different times/in different contexts.


I would need something more… conditional

IF openconnect is running and has modified resolv.conf, leave that file 
alone unless you are openconnect
Otherwise, when there's no VPN active, you can do normal DHCP requests 
and accept whatever currently-active network's router/DHCP tells you and 
update resolve conf accordingly



}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello,

On 2023-02-23 02:59, cono...@panix.com wrote:

On 2/22/23, daven...@tuxfamily.org  wrote:


There is an unidentified process that decides it's ok to delete and
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and
creates the file with wrong resolver's IP. The IP corresponds to my 
home
router IP, which does has a DNS resolver and it works as it should. 
BUT

my home's router DNS obviously don't know jack about work internal
servers, on which I work… and work's proxy as well, which when it 
cannot

be resolved… breaks everything using HTTP.


Might look at:

/etc/network/interfaces.d/setup

as explained in "man interfaces". (That file can/might be changed via
the network symbol in the window manager's configuration bar/menu
system, usually required with root/sudo privileges.)

John


There's nothing relevant to change in that file. I don't want to have 
static IP. And the right interface name is not in it.


I'm not sure whether that file became totally obsoleled, or if it's not 
normal that it doesn't contain the expected interface name? has it been 
deprecated since debian switched to systemd so-called "predictable" 
iface names?


For some reasons, since debian 9 or 10 (id nor 8?), including debian 11 
new installs (work laptop has been install slightly more than a year 
ago),
that files only contains the eth0 and local interfaces name, while 
debian switched to systemd style interfaces names.
I remembrer having slowed down boots because of the that, on my personal 
laptop, when debian switched to systemd style names and that file still 
referred to eth0 which doesn't exist
So boot process was waiting for eth0 interface until I commented out 
that part (eth0 block) of interfaces files.


On the newer work laptop on the other hand, there is that eth0 block, 
there's is no eth0 interface on my system (there's enp.* and enx.* 
systemd names, instead)
BUT I never had the slow/timeout-waiting boot process unlike the 
personal was reinstall from zero instead of upgraded years ago only to 
change HDD to SSD, and to change partitioning to encrypted LVM.


So my guess is /etc/network/interface.* has been replaced with something 
also. Since it refers to non-exitent interfaces names without breaking 
the network or slowing down the boot process.


Also, the switching to systemd styles interfaces names has been 
following by a weird behaviour on my personal computer. It has a 
"failed" error message at startup, for the network (or is networking? it 
never remember the correct name) service, without breaking the network… 
it weirdly just works. I never figured out what replaces that service. 
If anyone has any idea?

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Thu, Feb 23, 2023 at 10:44:35AM +0100, daven...@tuxfamily.org wrote:

[...]

> Thank you. I'll give it a try, But I won't be on remote work before next
> week
> Which log file is used for that?

That depends: it's the perpetrator's choice where to log (or whether
to log at all, sadly).

> So instead of grepping /var/log/ recursively when the problem occurs. I'd
> tail -f the right file to find the "rogue" process right away

You know that you can tail -f more than one file, do you?

I just learnt that from a colleague. Enormously handy.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello

On 2023-02-22 22:08, David Wright wrote:

On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:


What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN
(cleaning it's mess in the routing table, interfaces, /etc/resolv's
and other netwwork stuff it might have modified, makes sense)


What's the output from   ls -l /etc/resolv.conf



-rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf

With the ctime changing more or less often, since it is 
deleted/recreated by what I suspect to do DHCP requests (see audit.log)



What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.


openconnect does. When it's CTRL-C-ed to disconnect from the workplace 
VPN, resolv.conf is reverted back to my home network resolver
Not sure whether vpnc_script just calls the DHCP client (probably 
dhclient since it's the only dhcp client preinstalled, at least I'm 
aware of)





- I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
connmann as the default network manager) ships with systemd-resolvd
disabled and I'm totally OK with it
- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as
root. I used auditd to detect when changes that file… but I can't a
get any process name. I can just see it's root


One way of finding the process is to  # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)


Thank you. I'll give it a try, But I won't be on remote work before next 
week

Which log file is used for that?
So instead of grepping /var/log/ recursively when the problem occurs. 
I'd tail -f the right file to find the "rogue" process right away




But how do you manage /etc/resolv.conf with connman. I don't use it,


openconnect uses something called vpnc_script.
When openconnects is exc, resolv.conf contains the appropriate info as 
well a comment including "VPNC_GENERATED"



but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.


Whether it informs connmann or cleans after itself without involving 
connmann, I don't know and I'm not sure how to check that out.

I'm not familiar with how vpnc_script works and what it does _exactly_
But it does clean up the config and network config is left in working 
state when openconnect disconnects





I was expecting to see a process name it the audit.log file BUT it
didn't happened so I'm still stuck. so my question is: How to debug
that further, and identify the exact process that screw up with
/etc/resolv.conf file… So from there I could search for a way to
prevent that by modifying the rights config file or whatever…


Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)


Yes, I certainly don't want to block the process entirely, I just want 
to find some mechanism that works in the following way


"Leave /etc/resolv.conf alone, ONLY IF you're not openconnect/a 
vpnc_script AND WHEN openconnect is running"


Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be 
generated according to my home router's DHCP tells the computer


Thank you for your help either way. It gives me some interesting 
pointers :)




Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[John Conover]

On 2/22/23, daven...@tuxfamily.org  wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.

Might look at:

/etc/network/interfaces.d/setup

as explained in "man interfaces". (That file can/might be changed via
the network symbol in the window manager's configuration bar/menu
system, usually required with root/sudo privileges.)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Cindy Sue Causey]

On 2/22/23, daven...@tuxfamily.org  wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.


Hi.. I didn't know where to jump into this so am responding to that
paragraph in its original post. Having just debootstrap'ed again, one
thing I do is verify /etc/resolv.conf's content. The following,
slightly lengthy blurb has begun showing up where I'd never seen it
before. I'm sharing it with hopes maybe it hints at what might be a
trigger for the reset:

 BEGIN CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +
# This is /run/systemd/resolve/stub-resolv.conf managed by
man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
 END CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +

Those last three lines worked for Mint, but they did not work for
Debian. So I defiantly altered that file. I commented those three
lines out, tracked down my ISP's nameserver values,** and plugged them
in. I was able to connect immediately after that.

When I tried to do that with some other distribution, possibly Mint
again, it would reset as is being described in this thread and as is
seemingly implied in resolv.conf's "do not edit" line. I have no clue
why Debian is not resetting now, but I'm VERY grateful it's remaining
stable.

Having now actually read more of that blurb, I didn't follow any
symlinks. Thanks to issues over the years, /etc/resolv.conf is the
first place I go if an Internet connection is not working as expected.

Lastly, I just tried "ls -ld" on that long /run line to
stub-resolv.conf. It's "no such file" so that would explain why it's
not resetting on my end. Resolvectl is also pulling up as not found.

Those all definitely explain why I'm able to type online right now. If
I was feeling brave right now, I would try messing around with doing
what it takes to get resolvectl in control, but I'm not (feeling
brave). :)

Cindy :)

** My ISP's nameserver values were found in connman's GUI, of all
things. Connman has NEVER worked for me. I have no idea why it's
working now. I didn't manually install it. Connman came in
automatically somehow related to the LXQt desktop environment. Just
leaving this here in case it somehow is playing a part in why my
resolv.conf is not resetting. You never know..

-- 
Talking Rock, Pickens County, Georgia, USA
* GRUB IS WORKING! Just put ^ in front of metadata_csum_seed in mke2fs.conf! *

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:

> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN
> (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> and other netwwork stuff it might have modified, makes sense)

What's the output from   ls -l /etc/resolv.conf

What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.

> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
> connmann as the default network manager) ships with systemd-resolvd
> disabled and I'm totally OK with it
> - I do use connmann and didn't replace it with anything else
> - The process that deletes and recreates /etc/resolv.conf runs as
> root. I used auditd to detect when changes that file… but I can't a
> get any process name. I can just see it's root

One way of finding the process is to  # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)

But how do you manage /etc/resolv.conf with connman. I don't use it,
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.

> I was expecting to see a process name it the audit.log file BUT it
> didn't happened so I'm still stuck. so my question is: How to debug
> that further, and identify the exact process that screw up with
> /etc/resolv.conf file… So from there I could search for a way to
> prevent that by modifying the rights config file or whatever…

Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)

Cheers,
David.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, daven...@tuxfamily.org wrote:
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, [...]

Then it's probably the Debian DHCP client, rewriting resolv.conf
according to what your router's DHCP server told it to use.

 has several different strategies
for working around this sort of issue.

Good luck.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb daven...@tuxfamily.org:
> 
> = context =
> For the context, I use a Debian 11 laptop for work. When I work remotely
> from home, I have to use a cisco VPN. Good thing is there is openconnect,
> which does work, and in teh case of ym work's VPN, it does wor. cisco's
> spyware/downloaded binry, namely using the --csd-wrapper
> /usr/libexec/openconnect/"
[snip]
> = end of context =
> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN (cleaning
> it's mess in the routing table, interfaces, /etc/resolv's and other netwwork
> stuff it might have modified, makes sense)
> 
> Here's what I know:
> - Whatever process does that seems does what I highly suspect to be DHCP [1]
> requests every now and then. Home's router answers giving it's own address
> as both gateway and DNS resolver. And said process thinks it's OK to delete
> and recreate resolv.conf with the wrong content… breaking everything work's
> related while the VPN is still active

If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;
}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Roberto C . Sánchez]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, daven...@tuxfamily.org wrote:
> 
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,

I will admit up front that I did not read your message in great detail.
However, overall it seems like you are experiencing something similar to
what I experienced in the past.

Here was what I found and how I solved the problem:

https://lists.debian.org/debian-user/2017/10/msg00896.html

The entire thread is rather large, so I didn't just point you to the
beginning of it, but you might find other parts of the discussion
illuminating as well.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello,

= context =
For the context, I use a Debian 11 laptop for work. When I work remotely 
from home, I have to use a cisco VPN. Good thing is there is 
openconnect, which does work, and in teh case of ym work's VPN, it does 
wor. cisco's spyware/downloaded binry, namely using the --csd-wrapper 
/usr/libexec/openconnect/"


When I start openconnect, it usses some vpnc sript to write a porper, 
working, /etc/resolv.conf, with the right (work's) DNS resolver IP in 
it. And it works.
That worked flawlessly for months. But some months ago, probably after 
an upgrade or something (because I definitely didn't change anything), 
something started to screw up with /etc/resolv.conf.


So issue is not openconnect-related, at was just for the context. And to 
make it clear that totally disabling DHCP and writing the whole network 
config manually is not reasonably doable in my context. Because it's a 
laptop, sometime used with VPN, sometimes without it (even from home, 
occasionally, like during training on which I need to access external 
VMs that are not withelisted workplace's firewalls) so network context 
varies sometimes.

= end of context =

There is an unidentified process that decides it's ok to delete and 
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and 
creates the file with wrong resolver's IP. The IP corresponds to my home 
router IP, which does has a DNS resolver and it works as it should. BUT 
my home's router DNS obviously don't know jack about work internal 
servers, on which I work… and work's proxy as well, which when it cannot 
be resolved… breaks everything using HTTP.


What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN (cleaning 
it's mess in the routing table, interfaces, /etc/resolv's and other 
netwwork stuff it might have modified, makes sense)


Here's what I know:
- Whatever process does that seems does what I highly suspect to be DHCP 
[1] requests every now and then. Home's router answers giving it's own 
address as both gateway and DNS resolver. And said process thinks it's 
OK to delete and recreate resolv.conf with the wrong content… breaking 
everything work's related while the VPN is still active
- Such requests which varies a lot and inst consistent, can be twice or 
tree time in 10 minutes or 3-5 times during one afternoon…). sometimes 
it happens the minute after I restart the VPN client to recreate a 
working resolv.conf file, sometimes it leaves the file alone for 15, 
minutes or even 2-3 hours…
- I never configured anything that to do repetitive/time-random DHCP 
requests. Except of course the initial DHCP request the system is first 
started and connected in the morning when I satrt my work day, wich is 
configurerd by default when you install debian for desktop/laptop/with 
DEs and network managers and all the fancy stuff.
- I don't use systemd-resolvd. My OS image (Debian stable, LXDE, 
connmann as the default network manager) ships with systemd-resolvd 
disabled and I'm totally OK with it

- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as root. 
I used auditd to detect when changes that file… but I can't a get any 
process name. I can just see it's root
Here's what tail -f audit.log | grep --color resolv.conf shown what it 
happens


--
type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf" 
inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf" 
inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"

--

I was expecting to see a process name it the audit.log file BUT it 
didn't happened so I'm still stuck. so my question is: How to debug that 
further, and identify the exact process that screw up with 
/etc/resolv.conf file… So from there I could search for a way to prevent 
that by modifying the rights config file or whatever…


1. But didn't sniff network packets to confirma or infirm that, because 
I might wait for long time for it to happen, making extremely huge pcap 
files… Unless I know exactly what to filter out from input to have 
compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll 
end up with nothing. If I don't filter anything and it doesn't happen 
before 2 or 3 hours, it will take a shitload too much space form my home 
partition and would be PITA to use wireshark's search functions and 
display filters, and search for specific stuff, that will probably need 
several attempts with different search pattern an

consequences to deleting a (generic name) alternative? - reverse dependencies on ImageMagick binaries?

[Zenaan Harkness]

ImageMagick (IM) seems to be needed (at least on XFCE desktop) for
the PDF printer (cups-filters). There are many apparent rdepends of
IM, from a2ps and devede to inkscape and sunclock.

ImageMagick in Debian stable is a bit of a bush pig, dominating the
/usr/bin default PATH namespace with a number of excessively generic
verbs.

Although the files are apparently strictly versioned:

/usr/bin/animate-im6.q16
/usr/bin/compare-im6.q16
/usr/bin/composite-im6.q16
/usr/bin/conjure-im6.q16
/usr/bin/convert-im6.q16
/usr/bin/display-im6.q16
/usr/bin/identify-im6.q16
/usr/bin/import-im6.q16
/usr/bin/mogrify-im6.q16
/usr/bin/montage-im6.q16
/usr/bin/stream-im6.q16


, alternatives are put in place:

/usr/bin/animate -> /etc/alternatives/animate
/usr/bin/animate-im6 -> /etc/alternatives/animate-im6
/usr/bin/animate-im6.q16
/usr/bin/compare -> /etc/alternatives/compare
/usr/bin/compare-im6 -> /etc/alternatives/compare-im6
/usr/bin/compare-im6.q16
/usr/bin/composite -> /etc/alternatives/composite
/usr/bin/composite-im6 -> /etc/alternatives/composite-im6
/usr/bin/composite-im6.q16
/usr/bin/conjure -> /etc/alternatives/conjure
/usr/bin/conjure-im6 -> /etc/alternatives/conjure-im6
/usr/bin/conjure-im6.q16
/usr/bin/convert -> /etc/alternatives/convert
/usr/bin/convert-im6 -> /etc/alternatives/convert-im6
/usr/bin/convert-im6.q16
/usr/bin/display -> /etc/alternatives/display
/usr/bin/display-im6 -> /etc/alternatives/display-im6
/usr/bin/display-im6.q16
/usr/bin/identify -> /etc/alternatives/identify
/usr/bin/identify-im6 -> /etc/alternatives/identify-im6
/usr/bin/identify-im6.q16
/usr/bin/import -> /etc/alternatives/import
/usr/bin/import-im6 -> /etc/alternatives/import-im6
/usr/bin/import-im6.q16
/usr/bin/mogrify -> /etc/alternatives/mogrify
/usr/bin/mogrify-im6 -> /etc/alternatives/mogrify-im6
/usr/bin/mogrify-im6.q16
/usr/bin/montage -> /etc/alternatives/montage
/usr/bin/montage-im6 -> /etc/alternatives/montage-im6
/usr/bin/montage-im6.q16
/usr/bin/stream -> /etc/alternatives/stream
/usr/bin/stream-im6 -> /etc/alternatives/stream-im6
/usr/bin/stream-im6.q16


There is no "magick" command (or alternative), yet it seems as though
there is meant to be a "magick" program:
http://www.imagemagick.org/script/command-line-tools.php

Perhaps this "magick" command is only available in newer versions of
ImageMagick?


Anyway, "import" gets in the way, and others such as "convert",
"stream", "identify" and "display" really dominate those respective
generic namespaces, and in this particular case, are directly
obstructing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906674


"Alternatives" provides for choosing amongst "functionally the same"
alternatives, or "deleting" the generic name.


My question is, can I safely remove the symbolic link "generic"
names applied by the IM package, or IM's reverse dependencies going
to bite me?

TIA,

Re: Kmail - slow or no erasing of mails when deleting fast

[David Baron]

My Debian testing version is inoperative. Can no longer connect to Gmail.
Message preview box is black. A long time now. Latest upgrade is no better.

Since the main and left panes of system setup is also black, problem may be
kde.

On Tue, Apr 24, 2018, 8:59 AM Hans  wrote:

> Hi Marc,
> thanks for your reply.
> > Well ,
> >
> > Question, what version of KMail are you using (Help:About KMail)?
> >
>
> The version I am running here is 5.7.3, which is debian/testing and 32-bit.
> However, I have to tell, that I am watching this behaviour since a lng
> time, almost since the change to akonadi. At least for 3-4 years.
>
> I lived that long timer with this issue, but in the version I am using,
> things
> got worse. Now the "greyed out" mails are also, when marking them all and
> then
> move into the trash in one step.
> > I'm using version 5.5.2 and while some things are a bit slow, this
> version
> > is much better than those before it.  I've also seen "greyed out" e-mails
> > which were artifacts of the folder not being updated properly, and as you
> > point out, they go away when you force a folder refresh. Assuming you are
> > using a current version, I'd post a bug report on the KDE site:
> >
> > https://www.kde.org/applications/internet/kmail/
> >
> > If you are running an "old" version, your report will be ignored as work
> is
> > only done on new versions.
> >
> Hmm, I think this behaviour was ignored since a long time. I dunno, I
> believe
> I mentioned it some years ago in the forum, too, but nothing changed since.
>
> And I am not sure, if that can be fixed at all. Because: Who is to blame?
> (Sorry, if "blame" might be the wrong word, my English..., better say
> "ask"?)
>
> > Good luck,
> > Mark
>
> Best regards
>
> Hans
>
>
>
>

Re: Kmail - slow or no erasing of mails when deleting fast

[deloptes]

Hans wrote:

> Hmm, I think this behaviour was ignored since a long time. I dunno, I
> believe I mentioned it some years ago in the forum, too, but nothing
> changed since.
> 
> And I am not sure, if that can be fixed at all. Because: Who is to blame?
> (Sorry, if "blame" might be the wrong word, my English..., better say
> "ask"?)

The attitude of Kmail development/developers is to blame. Since they started
KDE4 it became unstable and unusable, pretty fragile. Each attempt to move
them to commit to stability first was rejected, because it was seen as a
slow down on the road map. The question what is it useful for if not
reliable was also ignored. I am suspecting conspiracy behind it - there is
no logical explanation - who is paying the work and why are they doing it -
it is a mystery to me. The obvious fact is that >KDE4 users are guinea pig.
Looking for alternative I came across a community that kept KDE3 alive under
the name of Trinity Desktop and I've been using it happily in the past 10y.
10y since KDE team promissed that KDE will become stable and usable soon.
Those guys are a joke. They might be good developers, but obviously the user
satisfaction are not on their priority list.

regards

Re: Kmail - slow or no erasing of mails when deleting fast

[Hans]

Hi Marc,
thanks for your reply.
> Well ,
> 
> Question, what version of KMail are you using (Help:About KMail)?
> 

The version I am running here is 5.7.3, which is debian/testing and 32-bit.
However, I have to tell, that I am watching this behaviour since a lng 
time, almost since the change to akonadi. At least for 3-4 years.

I lived that long timer with this issue, but in the version I am using, things 
got worse. Now the "greyed out" mails are also, when marking them all and then 
move into the trash in one step. 
> I'm using version 5.5.2 and while some things are a bit slow, this version
> is much better than those before it.  I've also seen "greyed out" e-mails
> which were artifacts of the folder not being updated properly, and as you
> point out, they go away when you force a folder refresh. Assuming you are
> using a current version, I'd post a bug report on the KDE site:
> 
> https://www.kde.org/applications/internet/kmail/
> 
> If you are running an "old" version, your report will be ignored as work is
> only done on new versions.
> 
Hmm, I think this behaviour was ignored since a long time. I dunno, I believe 
I mentioned it some years ago in the forum, too, but nothing changed since.
 
And I am not sure, if that can be fixed at all. Because: Who is to blame? 
(Sorry, if "blame" might be the wrong word, my English..., better say "ask"?)

> Good luck,
> Mark

Best regards

Hans

Re: Kmail - slow or no erasing of mails when deleting fast

[mark]

On Monday, April 23, 2018 3:07:49 AM EDT Hans wrote:
> Hi folks,
 

> I believe, that akonadi is to slow to write the changes into its database.
> When erasing mails slowly, then it is fast enough.
> 

Well ,

Question, what version of KMail are you using (Help:About KMail)?

I'm using version 5.5.2 and while some things are a bit slow, this version is 
much better than those before it.  I've also seen "greyed out" e-mails which 
were artifacts of the folder not being updated properly, and as you point out, 
they go away when you force a folder refresh. Assuming you are using a current 
version, I'd post a bug report on the KDE site:

https://www.kde.org/applications/internet/kmail/

If you are running an "old" version, your report will be ignored as work is 
only done on new versions.

Good luck,
Mark

Kmail - slow or no erasing of mails when deleting fast

[Hans]

Hi folks, 

there is a thing, I am noticing since kmail changed to akonadi. It would be 
nice, if someone can confirm or deny my noticing. 

The issue: When I want to delete lots of mails in my inbox folder, I am using 
the "delete" key of my keyboard. Doing so, one after the other mail is moved 
into trash. 

This is working, when I do it slow. But when I am deleting mails very fast, 
i.e. by depresing the delete key rapidly very fast, the mails are not moved 
into trash, but greyed out.

To fix this, I have to click another folder, then click back to inbox, and now 
I can go on erasing.

I believe, that akonadi is to slow to write the changes into its database. 
When erasing mails slowly, then it is fast enough. 

However, IMHO the database should be fast enough for these little changes, and 
it should just work one change after the other, independently of the speed of 
the input. And really: My depressing of the delete key is really slow related 
to the speed a computer can work!

Why do I tell all this now after such a long time? Just because today things 
are going worse. Now the above described behaviour has become "heavier", I 
must now delete with a longer delay. Additionally to delete the inbox folder 
by "mark all mails" and "move all mails to trash" does hardly work. I often 
have to do this repeatedly to get all mails moved (see above).

Just before I file a bug, it would be nice, if this can be confirmed or if 
this behaviour is known, or already be filed as a bugreport. 

And who is to inform? Is it akonadi or is it kmail?

Thanks for the patience to read this long mail. I hope we will find a way to 
improve things.

Best regards

Hans 

Re: Deleting i386 packages

[Eliezer Croitoru]

On 30/09/2015 14:53, Chris Bannister wrote:


Please don't top post on the debian-users mailing list


It was unintentional.

My main point stays.
An admin and IT manager needs to evaluate their goals and decide on the 
right approach.
Sometimes it can be frustrating to navigate between the drops and decide 
that a product that will survive for 3 years worth it.


I am working with both linux and windows, open-source and non-open 
source software.
I myself wrote a free software(3 clause BSD) but I have not published 
the actual code, and instead I have published the algorithm pesudo.(if 
you have the skills it's like copy and paste)
I have proved that my code is much more efficient then other software 
and which my software(SquidBlocker) gives more then others but still I 
have not seen a dime of it from anyone.

Not even one human contacted me and said "I want to try it".
And more then just that, admins prefer to use a very old product and 
which they say "it just works" when there is no support what so ever to 
the product and it doesn't utilize the resources of the system well 
leaving aside this product doesn't meet basic production systems goals.
And it's amazing that admins still prefer to use a software that was 
designed to be used in a very low load systems on a very high load 
system vs a system that was designed for 99% uptime and very high load.


So well, it's their choice and they will decide whatever they want.

All The Bests,
Eliezer


On Tue, Sep 29, 2015 at 07:33:52PM +0300, Eliezer Croitoru wrote:

Hey Chris,

It doesn't matter if some would like them to just vanish.
They do commit to the client but the scale of things might not be understood
by all in the same level\manner.
MS doesn't and cannot commit to software maintenance in certain levels.
I do not know how much money they have and indeed if they are committed to
PROFIT only with nothing else it would make them something else then what
they are.


I do know that:

1) They have (had?) a considerable amount of money put aside for
lawsuits against their business practices and their borg like behaviour
to small business where they liked a product of theirs.

Re: Deleting i386 packages

[Chris Bannister]

Please don't top post on the debian-users mailing list

On Tue, Sep 29, 2015 at 07:33:52PM +0300, Eliezer Croitoru wrote:
> Hey Chris,
> 
> It doesn't matter if some would like them to just vanish.
> They do commit to the client but the scale of things might not be understood
> by all in the same level\manner.
> MS doesn't and cannot commit to software maintenance in certain levels.
> I do not know how much money they have and indeed if they are committed to
> PROFIT only with nothing else it would make them something else then what
> they are.

I do know that:

1) They have (had?) a considerable amount of money put aside for
lawsuits against their business practices and their borg like behaviour
to small business where they liked a product of theirs.

2) A story I heard when Windows 95 was launched was they asked REM if
they could use their song 'Man On The Moon' but REM told them to shove
it in no uncertain terms, so they asked The Rolling Stones if they could
use their song "Start Me Up" and they said sure, for some exhorbitant
price, and apparently Microsoft didn't batter an eye, and just said
sure.

although this link:

http://www.networkworld.com/article/2220097/data-center/what-microsoft-paid-the-stones-to-help-launch-windows-95.html

seems to suggest it was way less than the amount I heard it was.

There was also some web pages written by an (ex?) employee of MS on why
he hated MS, (unfortunately, they seemed to buried in the huge number of
search results.) which were very interesting, there was about 9 pages
altogether, each one on a specific area. One in particular was about the
shoddy code. I wish I still had the link. :(

But the main thing I dislike about the MS OS, is the 'reverse logic'
they use in their menu selections and dialog boxes --- who knows it may
have been improved by now, but I've since moved on and have no real urge
to try it again. (once bitten twice shy, etc.)

I recently had a friend come round to use my wifi because her Windows
8.1 laptop, for some reason no longer thought that she was the owner of
it and had shut her out, she had to go through a laborious session of
sending emails and typing in codes she rec on her cell phone into boxes
on the laptop, and believe me; she was getting p***ed off fast. I
actually started to feel sorry for her when the dialog box was asking
for the six character code, but she had been only sent a four character
code. I mean how ridiculous is that? (considering she'd paid good money
for it.)

Nope, I steer clear of MS as much as possible, and just about any time
I've had to use it, I feel mentally drained and frustrated. At least if
a problem crops up in Linux, there's enough reasonable documentation
around so that you can troubleshoot your way through it without pulling
your hair out in the process.

P.S. I wonder if that is why Linux users tend to be hairy and MS users
tend to bald? :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: Deleting i386 packages

[Stuart Longland]

On 23/09/15 00:14, Reco wrote:
> $ dpkg -I teamviewer_10.0.46203_amd64.deb | grep Depe
>  Depends: bash (>= 3.0), libc6-i386 (>= 2.4), lib32asound2, lib32z1,
> libxext6, ia32-libs
> 
> A fine example of non-multiarch package which declared amd64 arch while
> providing i386 binaries only.

It was probably done that way before Debian became true multi-arch.

We had a similar thing in Gentoo, if you did `emerge skype`, that
required 32-bit libraries, that on the "AMD64" architecture, were
provided by packages in the app-emulation package.

Debian (and Gentoo) have since moved to true multi-arch, and so such
kludges are no longer required.  However there are still probably
packages floating around that still rely upon them.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature

Re: Deleting i386 packages

[Eliezer Croitoru]

Hey Chris,

It doesn't matter if some would like them to just vanish.
They do commit to the client but the scale of things might not be 
understood by all in the same level\manner.

MS doesn't and cannot commit to software maintenance in certain levels.
I do not know how much money they have and indeed if they are committed 
to PROFIT only with nothing else it would make them something else then 
what they are.
I do not need google to understand some fundamentals of business and 
basic software complexity assessment.
As I mentioned before, a complex software can be pretty hard to design 
and maintain.
One of the reasons RedHat and Suse are being used on many critical 
systems is due to the commitment that the vendor gives to supply support 
and updates for a very long period of time and as a result there is a 
feature freeze period.
If you will require services that are not available in the contract they 
will answer you all sort of things.
Sometimes they answer that they cannot do a thing about it and in other 
times they patch the software by themselves.
It is not far from MS but MS just does things in another way then it is 
being done on RedHat or Suse or others(externally).


As a side note, as much as I like google.. it's missing something and it 
will always be missing something.
It cannot replace the basic human understanding of life. With all it's 
CPUs, disks, applications, DBs, statistics etc it cannot and can never 
be more then a sum of about 64bits operations(yes yes maybe later it 
would be more then that).
If someone would ask you "do you want to see the world in 64 bits?" what 
would you prefer? a 64bits based world or a real world?


And no I have not tried to write a kernel or a gui or something similar 
since I think I would be the worst choice to make these and even if just 
to match msdos 6.2 with windows 3.11 capabilities.
And yes google gives me the option to run a search query like "download 
freedos" these days but still this is about it. It cannot give 
affection, warmth and many other things which people who work in MS 
tries to give everyday either to their surrounding MS employes or the 
users. And yes in a weird way which is being presented by a 64bit CPU.


Google, Linux, MS and others just do the same thing but in different shapes.

Eliezer

* I cannot count the number of people who hate google more then MS..

On 29/09/2015 07:51, Chris Bannister wrote:

On Sun, Sep 27, 2015 at 01:21:12PM +0300, Eliezer Croitoru wrote:

>Hey Martin,
>
>I was reading your note and it is not the reality or something that should
>be done but rather another side to consider when working with software
>vendors.
>I do agree that there is a benefit when the sources are open but companies
>like MS(just as an example) do not just vanish.

Some wish they would 'just vanish.'


>The above would be said for many other vendors that are committed to the
>client to support him.

They're not committed to the client, they're committed to PROFIT. It
doesn't take much googling to see some of the abysmal practices MS have
done over the years to see where their heart is.

Re: Deleting i386 packages

[Chris Bannister]

On Sun, Sep 27, 2015 at 01:21:12PM +0300, Eliezer Croitoru wrote:
> Hey Martin,
> 
> I was reading your note and it is not the reality or something that should
> be done but rather another side to consider when working with software
> vendors.
> I do agree that there is a benefit when the sources are open but companies
> like MS(just as an example) do not just vanish.

Some wish they would 'just vanish.'

> The above would be said for many other vendors that are committed to the
> client to support him.

They're not committed to the client, they're committed to PROFIT. It
doesn't take much googling to see some of the abysmal practices MS have
done over the years to see where their heart is.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: [OT] Free software vs non-free, here we go again (was: Deleting i386 packages)

[Reco]

 Hi.

On Sun, 27 Sep 2015 10:06:37 +0300
Eliezer Croitoru  wrote:

> Hey Reco,
> 
> I must admit that this is not the first time I was confused as a 
> trolling creature.

For the record - I did not 'confuse' you as a troll and did not call
you one. I could not care less about it, actually.


> And responding to the above mentioned arguments\ideas\thoughts.
> I know some might disagree with me about my point of view and I do not 
> have any obligations to change my mind but I can clarify my thoughts.
> 
> You have asked if I am a windows user and the answer is that I do use 
> windows and I find it a very nice piece of software.

Dear Eliezer. I don't *need* to ask you whenever you're using Windows
or not. E-mail headers 'User-Agent' and 'Content-Type' from your e-mails
leave me absolutely no doubt about you use Windows.

Also I must apologize in advance if I mistook your last name for the
first one. No offense meant.


> But I will need to clarify couple things since I am almost sure you 
> misinterpreted what I was writing.
> 
> There are couple things to consider with software.
> Like any other job the programmers need money and software authors are 
> not obligated  to publish their work to be available to all humanity(or 
> at-least these parts of humanity that are connected to the WWW).

True. To reduce free software concept to the availability of the source
code is gross oversimplification (and misses the point almost
completely btw), but we'll leave it here for a moment.


> The above is something I think is right and it is right especially for 
> security and health related software.

False. Please take your time to research 'Bugtraq' and
'Full-Disclosure' maillists to observe the falsehood of this statement.
Security by obscurity never works, and to promote such point of view
means to deny the truth.


> As opposed to what some think that software should be available for all 
> I am on the side which thinks that secrecy or confidentiality is a value 
> which is either required or wanted by people.

Here you've got it all wrong. You do not attach 'confidentiality' (let
along 'secrecy') labels to the software itself. You need to attach said
labels to the data which the software in question deals with.


> So the above doesn't implies that anyone should use any software. And 
> also in any case of software usage there is a great need to consider the 
> pros and cos and to see if it matches the requirements and needs.
> I am not writing and talking about debian specifically since this is not 
> the question(at-least from my side of the glass).
> 
> If some vendors supply compiled software that was audited by their 
> programmers, QA team and security personnel it is OK for me.

... And in real life that's not enough at all. Internal security audit
is a must, I agree. But unless the software in question is only used
internally by completely trusted personel - good, secure software
should be audited externally.
Inability to access the source code of said software is a serious
disadvantage in such a case.
Inability to *change* the source of said software equals inability to
use security-fixed software for large amounts of time (can be
sometimes remedied with assorted klugdes, true).
Inability to *deploy* the changed software (aka tivoized software) means
the same.


> If I pay for the software then it's fine from my side to get a packaged 
> product.

Ok. No arguments here. Note that free software does not equals zero
cost or lack of said 'packaged product'. Case study - Red Hat.


> I had a talk with a friend about the dangerous things on the Internet 
> and the conclusion was that some might not understand that the Internet 
> is just a "reflection" of the real world and there is no magic there.
> The same crooks can be found both in the real world and the Internet.

Ok. No arguments here too.


> In a case that a software vendor is suspected to be violating basic 
> security requirements intentionally it would black list the name brand 
> and the software.

False. There are numerous examples of the contrary. Starting with the
Microsoft, but not ending here.


> If we are talking about a complex piece of software then it is possible 
> that flaws do exist and it is also applies to any Linux and open source 
> software the same way(statistically) as non open source.

Oh, do I see 'They are bad too' argument here, right?


> Since I do have some experience with health care related programming 
> subjects and I do also have couple medical facilities that runs a 
> software with critical code I wrote and designed I can give a scenario.
> When a sysadmin decides on what software to use for these mission 
> critical human life related systems he needs to fully understand the 
> weight of using software(open source and non open source, free or non-free).
> He needs to be able to run a command such as "apt-get install squid" 
> without any fear that human life's would be affected by it.
> It means that he wil

Re: Deleting i386 packages

[Eliezer Croitoru]

Hey Martin,

I was reading your note and it is not the reality or something that 
should be done but rather another side to consider when working with 
software vendors.
I do agree that there is a benefit when the sources are open but 
companies like MS(just as an example) do not just vanish.
The above would be said for many other vendors that are committed to the 
client to support him.

I took an example and I stick with it:
The sysadmin and IT department needs to consider and evaluate what is 
their relationship with the software vendor and decide.
Sometimes they decide to open the source but only in-house due to the 
demand but it is still unrelated to "dangerous".
I agree that if we do not trust the vendor to test and patch it's 
software then it is a risk and when the sysadmin types "apt-get install 
tzdata" then he should understand that it will be updated.. and if not 
he(or somebody) can compile and update the tzdata files.


I have seen more then once that an open source distribution did not 
updated critical updates and admins was required to run some errands to 
make the software work.
I took tzdata package since it was a very major issue on many systems I 
have seen.


I still think that an institute small enough to not build it's own OS 
can asses it's requirements and decide that for example Debian is not 
for them and they prefer a specific vendor.
It's not dangerous and not reckless but a decision which considers what 
is good for the institute from couple aspects.

Many admins feels safe enough with Windows and not with Debian.
I have couple servers and desktops and I have seen bugs that was not 
fixed in Debian and the effort it will take from me to fix them will be 
more then to buy an Hyper-v or Vmware license.
So what if they are the only ones that can patch the software? they meet 
the institute global goals with a good price. is it that bad? no!


I remember that some admin I met showed me what he did to disable the 
apache server version advertisement.
Will it secure the service against some attacks? no, but F5, RADWARE and 
other companies products will indeed do that and in some cases it's 
cheaper then patching or upgrading a running system.


So still the argument that it's dangerous is not really an argument.
The state stays exactly the same: there is a risk that needs to be 
assessed and evaluated like in any software product and like any other 
chair in the planet.


All The Bests,
Eliezer

On 27/09/2015 11:47, Martin Read wrote:

On 27/09/15 08:06, Eliezer Croitoru wrote:

Like any other job the programmers need money and software authors are
not obligated  to publish their work to be available to all humanity(or
at-least these parts of humanity that are connected to the WWW).
The above is something I think is right and it is right especially for
security and health related software.


Security-related software is very *precisely* the kind that should not
be closed-source proprietary software, because when your security
software is proprietary, only the copyright holder has the right to
publish and distribute a fix for that piece of software when it turns
out to have a vulnerability.

And, of course, on an Internet-connected computer *most* software turns
out to be security-related.

Re: Deleting i386 packages

[Martin Read]

On 27/09/15 08:06, Eliezer Croitoru wrote:

Like any other job the programmers need money and software authors are
not obligated  to publish their work to be available to all humanity(or
at-least these parts of humanity that are connected to the WWW).
The above is something I think is right and it is right especially for
security and health related software.


Security-related software is very *precisely* the kind that should not 
be closed-source proprietary software, because when your security 
software is proprietary, only the copyright holder has the right to 
publish and distribute a fix for that piece of software when it turns 
out to have a vulnerability.


And, of course, on an Internet-connected computer *most* software turns 
out to be security-related.

Re: Deleting i386 packages

[Eliezer Croitoru]

Hey Reco,

I must admit that this is not the first time I was confused as a 
trolling creature.


And responding to the above mentioned arguments\ideas\thoughts.
I know some might disagree with me about my point of view and I do not 
have any obligations to change my mind but I can clarify my thoughts.


You have asked if I am a windows user and the answer is that I do use 
windows and I find it a very nice piece of software.
But I will need to clarify couple things since I am almost sure you 
misinterpreted what I was writing.


There are couple things to consider with software.
Like any other job the programmers need money and software authors are 
not obligated  to publish their work to be available to all humanity(or 
at-least these parts of humanity that are connected to the WWW).
The above is something I think is right and it is right especially for 
security and health related software.
As opposed to what some think that software should be available for all 
I am on the side which thinks that secrecy or confidentiality is a value 
which is either required or wanted by people.


So the above doesn't implies that anyone should use any software. And 
also in any case of software usage there is a great need to consider the 
pros and cos and to see if it matches the requirements and needs.
I am not writing and talking about debian specifically since this is not 
the question(at-least from my side of the glass).


If some vendors supply compiled software that was audited by their 
programmers, QA team and security personnel it is OK for me.
If I pay for the software then it's fine from my side to get a packaged 
product.
I had a talk with a friend about the dangerous things on the Internet 
and the conclusion was that some might not understand that the Internet 
is just a "reflection" of the real world and there is no magic there.

The same crooks can be found both in the real world and the Internet.
In a case that a software vendor is suspected to be violating basic 
security requirements intentionally it would black list the name brand 
and the software.
If we are talking about a complex piece of software then it is possible 
that flaws do exist and it is also applies to any Linux and open source 
software the same way(statistically) as non open source.


Since I do have some experience with health care related programming 
subjects and I do also have couple medical facilities that runs a 
software with critical code I wrote and designed I can give a scenario.
When a sysadmin decides on what software to use for these mission 
critical human life related systems he needs to fully understand the 
weight of using software(open source and non open source, free or non-free).
He needs to be able to run a command such as "apt-get install squid" 
without any fear that human life's would be affected by it.
It means that he will have someone that he can trust to test it 
externally and verify it fits the purpose or that the software was 
tested enough by the developers and by the distribution team.
Free and non Free, open source or non open source is not the question at 
all in this case.
For some, when looking at a non-free software in banking or health care 
the question is not if it is more dangerous since the main question and 
almost only question is "is this piece of software fit for this role I 
requrie?" and it contains kind of "recursively" security and operations 
sides.


The only dangerous software is a "dangerous" software!
The definition of dangerous is not by free or non free, open source or 
none open source.
It's a subject by itself that requires a new definition in any software 
adoption steps.
Would a bug in exim, a fatal one, makes exim a dangerous piece of 
software? The answer is that in some cases it would indeed do that but 
in other cases it would be dangerous the same way as postfix or MS exchange.


You can have arguments about a specific vendor\provider\programmer 
software or a repository based on it's characteristics and statistically 
it might fit debian non-free repo but it cannot make all non-free 
software out-there to be dangerous and it's not an argument from debian 
non-free to other software or from other software to debian non-free.


A part of the health care facility sysadmin duties is to make sure that 
he can maintain the software or at-least to make sure that there are 
out-there developers, testers and others who can answer the facility 
requirements.
The above is one of the main reasons that many sysadmins prefer to use 
RedHat and Windows despite the fact that both companies cannot always be 
aware of very critical bugs.

This is not what makes these companies and their software dangerous.

If you do feel that this is what makes software dangerous indeed it's an 
argument but it might not meet reality or reality requirements in many 
facilities.


Then, what do you mean by dangerous? it was not really clear from your 
words.


Thanks,
Eliezer

On 25/09/2015 15:26, R

Re: Deleting i386 packages

[Reco]

On Fri, Sep 25, 2015 at 09:54:05PM +1200, Chris Bannister wrote:
> On Thu, Sep 24, 2015 at 01:24:45PM +0300, Reco wrote:
> > Hi.
> > 
> > On Thu, Sep 24, 2015 at 07:36:32AM +0300, Eliezer Croitoru wrote:
> > > I will not argue since truth can be seen from more then one side.
> > > Proprietary software usage is normal in all cases.
> > 
> > No surprise in such position here, since apparently you're using Windows.
> > And you came to the wrong place to promote such view of things.
> 
> I believe you have just been trolled! :)

Let's recount.

Number of personal attacks - 0.
Number of naughty words - 0.
Number of off-list e-mails with kill threats/suicide propositions - 0.
Number of doxxings - 0.
Number of kittens harmed - 0.
Windoze users fended off - 1.

Nope, I have to disagree with your assertion :)

Therefore, my point stands unchallenged - non-free software users should
suffer anyway.

Reco

Re: Deleting i386 packages

[Chris Bannister]

On Thu, Sep 24, 2015 at 01:24:45PM +0300, Reco wrote:
>   Hi.
> 
> On Thu, Sep 24, 2015 at 07:36:32AM +0300, Eliezer Croitoru wrote:
> > I will not argue since truth can be seen from more then one side.
> > Proprietary software usage is normal in all cases.
> 
> No surprise in such position here, since apparently you're using Windows.
> And you came to the wrong place to promote such view of things.

I believe you have just been trolled! :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: Deleting i386 packages

[Reco]

Hi.

On Thu, Sep 24, 2015 at 07:36:32AM +0300, Eliezer Croitoru wrote:
> I will not argue since truth can be seen from more then one side.
> Proprietary software usage is normal in all cases.

No surprise in such position here, since apparently you're using Windows.
And you came to the wrong place to promote such view of things.

But I disagree with you. It boils down to the question of control. As
long as you cannot change the software in question if needed - you're
not in control. They do.

As for 'all cases':

Is it OK to do banking using non-free software?
Is it OK to trust healthcare of personal information to non-free
software?


> It is as dangerous as the usage of open source software.

No it's more dangerous. See above about control.


> It might limit but it gives something that not all open source software can
> give.

Which is? What's that magical thing?


> It doesn't limit freedom but just a mere functionality "limit" like any
> other software that exists and will exist ever.

No. Existence or absence of functionality is the question of change.
With the free software you can make the needed change.
With the non-free software you cannot.


> Software is Software and if someone requires something it doesn't matter if
> it fits the needs.

Nope. Non-free software usually comes with restrictions in field of
usage or other completely artificial restrictions.

Reco

Re: Deleting i386 packages

[Eliezer Croitoru]

I will not argue since truth can be seen from more then one side.
Proprietary software usage is normal in all cases.
It is as dangerous as the usage of open source software.
It might limit but it gives something that not all open source software 
can give.
It doesn't limit freedom but just a mere functionality "limit" like any 
other software that exists and will exist ever.
Software is Software and if someone requires something it doesn't matter 
if it fits the needs.


All The Bests,
Eliezer

On 22/09/2015 17:01, Reco wrote:

Using proprietary software is not normal. It's dangerous. It limits
one's freedom. And IMO it definitely should not be encouraged on
*Debian*  user maillist.

Reco

Re: Deleting i386 packages

[Reco]

 Hi.

On Tue, Sep 22, 2015 at 09:06:47PM +0800, mudongliang wrote:
> Or some of 64bit software will not work if you don't check.
> For example , skype ,teamviewer all need i386 packages.
> 
> 1) Users of non-free software (especially users of non-free wine-embedded
> software) should suffer anyway.
> 
> 2) Which part of teamviewer is 64bit?
> 
> Its webiste shows 32-Bit / 64-Bit Multiarch! If you install multiarch, the 
> dpkg shows you :
> 
> $ dpkg -l | grep teamviewer
> ii  teamviewer  10.0.41499
>   amd64    TeamViewer (Remote Control Application)

$ dpkg -I teamviewer_10.0.46203_amd64.deb | grep Depe
 Depends: bash (>= 3.0), libc6-i386 (>= 2.4), lib32asound2, lib32z1,
libxext6, ia32-libs

A fine example of non-multiarch package which declared amd64 arch while
providing i386 binaries only.

Also it won't be affected by removal of i386 packages as it depends on
amd64 packages only.

Of course, they may have changed it from version 10.0.41499 I've just
downloaded, but I doubt it.


> And skype :
> 
> $ dpkg -l | grep skype
> ii  skype    4.3.0.37-0ubuntu0.12.04.1
>     amd64    client for Skype VOIP and instant messaging service
> ii  skype-bin    4.3.0.37-0ubuntu0.12.04.1
>     i386 client for Skype VOIP and instant messaging service - 
> binary
> files

In this case I agree that 'apt-get remove .*:i386' should get rid of
skype-bin. Which will be clearly expressed by apt, giving the user a
chance to bail out.

So again, no custom checks are needed.

Reco

Re: Deleting i386 packages

[Reco]

On Tue, Sep 22, 2015 at 02:25:20PM +0100, Martin Read wrote:
> On 22/09/15 13:38, Reco wrote:
> >1) Users of non-free software (especially users of non-free wine-embedded
> >software) should suffer anyway.
> 
> It speaks ill of you that you cite this as a reason for not offering
> cautionary advice to users of proprietary software.

Probably. Still, if OP wishes to purify his amd64 installation by
removing unneeded i386 parts by clearly expressing his wish to do so (in
the e-mail), it seems rude to assume that those i386 parts were serving
as a mere compatibility shim to some proprietary blob.

Using i386 packages on amd64 install is not limited by this usecase.


> If such people *do* in fact deserve suffering, I submit that their use of
> proprietary software will provide all the suffering they deserve, and that
> their suffering need not be compounded by the behaviour of advocates for
> libre software.

Call it 'raising the awareness' then. Or 'zero tolerance policy'. Or
whatever newspeak term they invented for this.

Using proprietary software is not normal. It's dangerous. It limits
one's freedom. And IMO it definitely should not be encouraged on
*Debian* user maillist.

Reco

Re: Deleting i386 packages

[Martin Read]

On 22/09/15 13:38, Reco wrote:

1) Users of non-free software (especially users of non-free wine-embedded
software) should suffer anyway.


It speaks ill of you that you cite this as a reason for not offering 
cautionary advice to users of proprietary software.


If such people *do* in fact deserve suffering, I submit that their use 
of proprietary software will provide all the suffering they deserve, and 
that their suffering need not be compounded by the behaviour of 
advocates for libre software.

Re: Deleting i386 packages

[mudongliang]

On 09/22/2015 08:38 PM, Reco wrote:

On Tue, Sep 22, 2015 at 03:43:48PM +0800, mudongliang wrote:


On 09/22/2015 02:49 PM, Reco wrote:

Hi.

On Mon, Sep 21, 2015 at 09:18:01PM -0600, Joe Pfeiffer wrote:

For historical reasons, my x86-64 architecture computers have a large
number of i386 packages on them that I'd just as soon be rid of.  is
there a good way to simply tell a package manager that I want everything
involving that architecture deleted?  The best answer I've found on my
own has been to use dpkg and grep to find everything with :i386, and
then construct a huge dpkg --purge command to get rid of them all.
Hoping for something a little simpler...

Try this:

apt-get remove --purge .*:i386

Before you do this dangerous command , please check all your 64bit software
and make sure they don't need any i386 package.

No stock Debian amd64 package should require a i386 package.

Yes ,you're right!




Or some of 64bit software will not work if you don't check.
For example , skype ,teamviewer all need i386 packages.

1) Users of non-free software (especially users of non-free wine-embedded
software) should suffer anyway.

2) Which part of teamviewer is 64bit?
Its webiste shows 32-Bit / 64-Bit Multiarch! If you install multiarch, 
the dpkg shows you :


$ dpkg -l | grep teamviewer
ii  teamviewer 10.0.41499  amd64 
TeamViewer (Remote Control Application)


And skype :

$ dpkg -l | grep skype
ii  skype 4.3.0.37-0ubuntu0.12.04.1amd64client for 
Skype VOIP and instant messaging service
ii  skype-bin 4.3.0.37-0ubuntu0.12.04.1i386 client 
for Skype VOIP and instant messaging service - binary files


- mudongliang


Reco

Re: Deleting i386 packages

[Reco]

On Tue, Sep 22, 2015 at 03:43:48PM +0800, mudongliang wrote:
> 
> 
> On 09/22/2015 02:49 PM, Reco wrote:
> > Hi.
> >
> >On Mon, Sep 21, 2015 at 09:18:01PM -0600, Joe Pfeiffer wrote:
> >>For historical reasons, my x86-64 architecture computers have a large
> >>number of i386 packages on them that I'd just as soon be rid of.  is
> >>there a good way to simply tell a package manager that I want everything
> >>involving that architecture deleted?  The best answer I've found on my
> >>own has been to use dpkg and grep to find everything with :i386, and
> >>then construct a huge dpkg --purge command to get rid of them all.
> >>Hoping for something a little simpler...

> >Try this:
> >
> >apt-get remove --purge .*:i386

> Before you do this dangerous command , please check all your 64bit software
> and make sure they don't need any i386 package.

No stock Debian amd64 package should require a i386 package.


> Or some of 64bit software will not work if you don't check.
> For example , skype ,teamviewer all need i386 packages.

1) Users of non-free software (especially users of non-free wine-embedded
software) should suffer anyway.

2) Which part of teamviewer is 64bit?

Reco

Re: Deleting i386 packages

[Mirko Parthey]

On Mon, Sep 21, 2015 at 09:18:01PM -0600, Joe Pfeiffer wrote:
> For historical reasons, my x86-64 architecture computers have a large
> number of i386 packages on them that I'd just as soon be rid of.  is
> there a good way to simply tell a package manager that I want everything
> involving that architecture deleted?  The best answer I've found on my
> own has been to use dpkg and grep to find everything with :i386, and
> then construct a huge dpkg --purge command to get rid of them all.
> Hoping for something a little simpler...

# aptitude --purge-unused markauto "~ri386"

This should only remove packages that are not needed anymore,
assuming that nobody messed up the auto markings of your installed
packages.

At the yes/no prompt, you might want to check the list of packages to be
purged.
You could also run a first pass without "--purge-unused", check if you are
happy with the results, then do a second pass with this option included.

Regards,
Mirko

Re: Deleting i386 packages

[mudongliang]

On 09/22/2015 02:49 PM, Reco wrote:

Hi.

On Mon, Sep 21, 2015 at 09:18:01PM -0600, Joe Pfeiffer wrote:

For historical reasons, my x86-64 architecture computers have a large
number of i386 packages on them that I'd just as soon be rid of.  is
there a good way to simply tell a package manager that I want everything
involving that architecture deleted?  The best answer I've found on my
own has been to use dpkg and grep to find everything with :i386, and
then construct a huge dpkg --purge command to get rid of them all.
Hoping for something a little simpler...

Try this:

apt-get remove --purge .*:i386
Before you do this dangerous command , please check all your 64bit 
software and make sure they don't need any i386 package.

Or some of 64bit software will not work if you don't check.
For example , skype ,teamviewer all need i386 packages.
- mudongliang


Reco

Re: Deleting i386 packages

[Reco]

Hi.

On Mon, Sep 21, 2015 at 09:18:01PM -0600, Joe Pfeiffer wrote:
> For historical reasons, my x86-64 architecture computers have a large
> number of i386 packages on them that I'd just as soon be rid of.  is
> there a good way to simply tell a package manager that I want everything
> involving that architecture deleted?  The best answer I've found on my
> own has been to use dpkg and grep to find everything with :i386, and
> then construct a huge dpkg --purge command to get rid of them all.
> Hoping for something a little simpler...

Try this:

apt-get remove --purge .*:i386

Reco

Re: Deleting i386 packages

[Himanshu Shekhar]

You should probably avoid doing so. We are using systems based on amd64 (64
bit) architecture, still there are many applications that yet depend on the
i386 (32 bit) model. 64 bit processors allow 32 apps to run, which lets
them function properly on modern computers too.
i386 packages should not worry you much, and you may need some of them
badly, if I am not wrong.

Happy computing!

On Tue, Sep 22, 2015 at 8:48 AM, Joe Pfeiffer  wrote:

> For historical reasons, my x86-64 architecture computers have a large
> number of i386 packages on them that I'd just as soon be rid of.  is
> there a good way to simply tell a package manager that I want everything
> involving that architecture deleted?  The best answer I've found on my
> own has been to use dpkg and grep to find everything with :i386, and
> then construct a huge dpkg --purge command to get rid of them all.
> Hoping for something a little simpler...
>
>


-- 
Himanshu Shekhar
IIIT-Allahabad
IRM2015006

Deleting i386 packages

[Joe Pfeiffer]

For historical reasons, my x86-64 architecture computers have a large
number of i386 packages on them that I'd just as soon be rid of.  is
there a good way to simply tell a package manager that I want everything
involving that architecture deleted?  The best answer I've found on my
own has been to use dpkg and grep to find everything with :i386, and
then construct a huge dpkg --purge command to get rid of them all.
Hoping for something a little simpler...

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

On 20150420_1252-0500, David Wright wrote:
> Quoting David Wright (deb...@lionunicorn.co.uk):
> > Quoting Paul E Condon (pecon...@mesanetworks.net):
> > > On 20150402_2135-0500, David Wright wrote:
> > > > I do get occasional I/O errors on USB transfers, which can make the
> > > > disk readonly, but sometimes make it disappear altogether (ie it
> > > > gets unmounted, not remounted).
> > > 
> > > All of my file systems are journaled. Did you notice a delay in remount
> > > as the journal was replayed?
> > 
> > No, but I wasn't watching for it. I will in future (though obviously
> > I have adjusted my working practice to minimise the rare occurrences).
> 
> ... and my current workaround is to use my little old laptop to copy
> files between USB drives. I just copied 120,000 files (45.5GB) without
> a peep on /var/log/kern.log, not even one of those interface reset
> messages that my desktop often logs.
> 
> Cheers,
> David.

Thanks for the report.
I haven't had a I/O error event in quite a while, also.
But I have become embroiled it other issues involving installing Jessie.
I hope the problem is truly fixed, but I continue to have other problems,
some of which preclude me running long I/O intencive jobs.

Cheers,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150421151722.gb6...@big.lan.gnu

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[David Wright]

Quoting David Wright (deb...@lionunicorn.co.uk):
> Quoting Paul E Condon (pecon...@mesanetworks.net):
> > On 20150402_2135-0500, David Wright wrote:
> > > I do get occasional I/O errors on USB transfers, which can make the
> > > disk readonly, but sometimes make it disappear altogether (ie it
> > > gets unmounted, not remounted).
> > 
> > All of my file systems are journaled. Did you notice a delay in remount
> > as the journal was replayed?
> 
> No, but I wasn't watching for it. I will in future (though obviously
> I have adjusted my working practice to minimise the rare occurrences).

... and my current workaround is to use my little old laptop to copy
files between USB drives. I just copied 120,000 files (45.5GB) without
a peep on /var/log/kern.log, not even one of those interface reset
messages that my desktop often logs.

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420175204.GB10624@alum

Small ARM file server (was: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.)

[Bob Proulx]

Stefan Monnier wrote:
> (BTW, I now use a Banana Pi connected via ethernet as a "drive
> enclosure" instead: it doesn't even consume more power than the
> external power supply of my previous enclosure).

I have been playing with the Banana Pi recently too.  It is quite a
nice little dual core ARM machine.  It runs stock Debian.  I haven't
had a chance to set up a SATA disk on it yet however.  I have only
been using the SD card just like the Raspberry Pi.  I have several of
the Raspberry Pis too and the Banana Pi is definitely a faster more
responsive system.

> Same here.  Only problem is that my Fit-PC2 (to which I need to connect
> that drive) only has 1 sata port and it's already got another drive.

I have been contemplating two Banana Pis.  Each with one SATA SSD.
Then mirror the two systems using DRBD.  That would be complete system
redundancy.  Not a really high performance system but probably quite
good for a home system.

> Another problem with eSata is the power

My good eSATA enclosure uses a separate power plug.

Bob


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Stefan Monnier]

> In the environment you described I would not be worried.  I have never
> lost any data on my USB mounted disks.  You sound like you are
> mounting your device for backup, using it, then unmounting it until
> needed again.  I have never had any problems doing that.  I think you
> could continue that without any hesitation.
>
> In my case leaving a USB disk *mounted* for a long time and in active
> use always resulted in the device eventually (month, two months)
> reporting I/O errors which caused the kernel to kick the device out of
> the system.  I would need to power cycle the enclosure.  After a power
> cycle and a remove and replace then I could mount it again.

FWIW, my experience has been identical to yours (BTW, I now use a
Banana Pi connected via ethernet as a "drive enclosure" instead: it
doesn't even consume more power than the external power supply of my
previous enclosure).

> I like eSATA as it is simply an external SATA.  For enclosures that
> simply cable the SATA to the drive it is as reliable as an internal
> SATA drive.

Same here.  Only problem is that my Fit-PC2 (to which I need to connect
that drive) only has 1 sata port and it's already got another drive.

Another problem with eSata is the power

> How will you know if money equals value?  It is a Market for Lemons.
>   http://en.wikipedia.org/wiki/The_Market_for_Lemons

Actually, I haven't found much variation at all between different kinds
of USB<->Sata converters and drive enclosures.  I've had a few expensive
brand-name ones and various cheap ones, and they all had pretty much the
same reliability (or lack thereof).  Also there was no correlation
between the price and the "featureset" (to me, the most important ones
being whether the SMART commands were passed through and even more
importantly whether hdparm could be used to control the spin-down time).

> I can't recommend spending more money.  The odds are good that it
> would be a waste of money.

That's also my experience.

> > I'm looking at this:
> > http://www.amazon.co.uk/Akasa-AK-CBSA03-80BK-Flexstor-eSATA-Cable/dp/B005GNP72M
> > + caddy (let's say).

Looks good.  If you find a cable that does only the power half of that
cable (i.e. USB to Sata-power), let me know.

> Just beware of the power drain of the device.  The USB power limit on

Usually, the max-power drain is at spin-up, so if the drive starts,
you should be good (unless the power delivered to your USB port might
depend on other factors, in which case you need to check that the drive
can spin-up even when the rest of the system is maximally loaded).


Stefan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/jwvtwwqu6do.fsf-monnier+gmane.linux.debian.u...@gnu.org

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

Curt wrote:
> Bob Proulx wrote:
> > HOWEVER!  It is a big however.  I can't find any _new_ eSATA
> > enclosures that are not also USB enclosures and do not now include
> > active electronics in the connection between the eSATA and the drive.
> > That's bad IMNHO.  It introduces cheap electronics in the disk path
> > that is unwanted and unneeded.
> 
> I'm looking at this:
> http://www.amazon.co.uk/Akasa-AK-CBSA03-80BK-Flexstor-eSATA-Cable/dp/B005GNP72M
> + caddy (let's say).
> 
> Would this suffer from the fragility you're talking about?  

First I must say that I don't know anything specific about that
particular adapter.  Buyer beware.  However looking at it and reading
the reviews leads me to believe that it is a pure adapter and no
active electronics in it.  Looks good to me!  I would use it.  Should
work nicely.  Looks to be just an eSATA cable.  That is what you want.
(It isn't an enclosure however.)

My only concern would be providing enough power through the USB.  It
looks to use a single USB connector to obtain up to 0.5A.  That is
enough for an SSD.  It is likely enough for a low power laptop 2.5
inch spinning hard drive.  Although usually those use two USBs to get
up to 1A.  It would not be enough for a 3.5 inch desktop spinning hard
drive.  It would be too power hungry.

Just beware of the power drain of the device.  The USB power limit on
a power hungry device could probably be mitigated by using a suitable
power charger USB socket.  Probably using a mobile cell phone charger
USB socket instead of the computer USB would be sufficient on
something marginal.  Or one of the USB power adapters designed for the
Raspberry Pi would supply even a hungry spinning desktop drive.  I
would take a try it and see attitude.  If it all works well then it
works well.  Stop analyzing it and simply use it.  Looks good to me.

Bob


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Curt]

On 2015-04-06, Bob Proulx  wrote:
>
> HOWEVER!  It is a big however.  I can't find any _new_ eSATA
> enclosures that are not also USB enclosures and do not now include
> active electronics in the connection between the eSATA and the drive.
> That's bad IMNHO.  It introduces cheap electronics in the disk path
> that is unwanted and unneeded.
>

I'm looking at this:

http://www.amazon.co.uk/Akasa-AK-CBSA03-80BK-Flexstor-eSATA-Cable/dp/B005GNP72M

+ caddy (let's say).

Would this suffer from the fragility you're talking about?  


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnmi819f.2bs.cu...@einstein.electron.org

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

Paul E Condon wrote:
> On rereading my message, I can see why you are unhappy and offended.

I was neither unhappy nor offended.  I am sorry if my responses
indicated any such thing.  I went back and read what I wrote and I am
at a loss to know where I went wrong.  Please let me know so that I
can avoid causing this misunderstanding in the future.

> Between making ill advised posts here, I have been searching the web.
> I found two sources that I wish had known about, but didn't.
> 
> One is the Backblaze.com web site. Their marketing actually contains
> some real technical information on modern HD technology.
> 
> And an article in Wikipedia on the history of disk storage:
> (http://en.wikipedia.org/wiki/Hard_disk_drive) and other articles that
> are linked from there. I learned things that you might think everyone
> knows, but I didn't.

Good stuff there.

> And, the newer high information density drives all have a supply of
> reserve sectors which they use to automatically replace sectors that
> are showing signs of incipient failure.

Yes.  Drives in the last decade have reserve sectors.  Blocks are
mapped internally in the controller between the logical address and a
physical address.  On the outside we only see logical block
addressing.  Those addresses are logical and the controller may put
them anywhere on the physical disk.  On the inside it could be
anywhere.  There is no one-to-one mapping anymore.  This is taken the
toe extreme with newer SSDs that *continuously* remap blocks.

> All of the disks in USB packaging that I have had are ones for which
> these facts apply. If one is gathering the right data while using
> them, one can predictably when they cannot continue to serve, that is
> when, for each disk individually, its supply of reserve sectors runs
> out. Other random failures can shorten the life to something less can
> cause failure when there is still a supply of 'reserve' sectors.

I am skeptical about being able to accurately predict a drive failing.
However I try to replace drives in single drive systems when the
reserve blocks are exhausted.  At that point the next consumption
would result in data loss.  The drive hasn't failed yet.  But if it
continues then it will.  Sometimes that might be yet years later in
the future.  I use those drives in victim systems for installation
testing and other non-critical uses.  The drives are still useful.
But I costs being inexpensive for replacements I don't want to hassle
and panic with a problem on a critical system.  But all of my critical
systems are in a RAID configuration to avoid any single disk fault.

> The technical basis of the Backblaze business monitoring all the spinning
> reserve (which is a borrowed technical term from the electrical power
> industry where it means a dynamo that is already spinning but is not
> actually delivering power to the grid).
> 
> I certainly wasn't keeping records of HD performance the way Backblase
> says they do. I am rethinking. I think I need to be quiet for awhile.

In RAID systems I replace drives when the drive actually fails.  But I
do so as quickly as practical!  It would be bad if the other drive
failed too before the failed one was replaced.  I know some hosting
providers simply replace drives based upon age since there is no
really accurate predictor.  For my systems monitoring the raid is
sufficient.

Bob


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

Petter Adsen wrote:
> Reading your previous mails make me a little worried, though. It is
> only used as a sort of semi-online backup, that I connect when I run
> the backup, but my main backups are on bluray-discs. Now I begin to
> wonder if I should invest in another drive for backing up stuff, but I
> would still want it to be removable.

In the environment you described I would not be worried.  I have never
lost any data on my USB mounted disks.  You sound like you are
mounting your device for backup, using it, then unmounting it until
needed again.  I have never had any problems doing that.  I think you
could continue that without any hesitation.

In my case leaving a USB disk *mounted* for a long time and in active
use always resulted in the device eventually (month, two months)
reporting I/O errors which caused the kernel to kick the device out of
the system.  I would need to power cycle the enclosure.  After a power
cycle and a remove and replace then I could mount it again.

I have never lost any data when the kernel has kicked the USB device
out of my system.  It simply caused me to need to manually remove and
insert the USB again.  That makes it for a very unreliable system for
me since I value systems not crashing.  But I never lost any data.

Previously the oldest USB enclosures would not pass through SMART
commands to the disk.  A disk in a USB enclosure would be impossible
to use with SMART.  ('smartctl -i /dev/sdg')  But newer models now
support passing these commands through.  I am just noting it as
another "hacky" thing about the cheap enclosures.

> That means I have to decide between eSATA and IEEE-1394 as interfaces.
> Only this machine has eSATA, I think, while both machines I might want
> to connect it to has Firewire. Which of these would be the best choice
> from a technical standpoint, and do they work well with Linux? I'd
> imagine eSATA would simply be seen as a SATA device?

I like eSATA as it is simply an external SATA.  For enclosures that
simply cable the SATA to the drive it is as reliable as an internal
SATA drive.

HOWEVER!  It is a big however.  I can't find any _new_ eSATA
enclosures that are not also USB enclosures and do not now include
active electronics in the connection between the eSATA and the drive.
That's bad IMNHO.  It introduces cheap electronics in the disk path
that is unwanted and unneeded.

I have an older eSATA without any active electronics and it has been
100% good.  IF I could find more of those that is what I would buy.
Unfortunately the newer eSATA interfaces I have acquired now have the
cheap electronics in between.  I haven't any data showing they cause
problems but I am suspicious.  Personally being an EE my plan if I
need one is to cut-n-jumper around it.  Simply route the SATA cable
directly to the drive to avoid any problem with the cheap electronics.
I doubt non-EE types would want to go that route however.  I can only
submit a general caution.

> Might it also be better to go with a little bit more expensive
> enclosure?

How will you know if money equals value?  It is a Market for Lemons.

  http://en.wikipedia.org/wiki/The_Market_for_Lemons

I can't recommend spending more money.  The odds are good that it
would be a waste of money.

Bob


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Linux-Fan]

[Sat, 4 Apr 2015 09:44:13 +0200] Petter Adsen  wrote:
> On Fri, 3 Apr 2015 15:01:26 -0600
> Bob Proulx  wrote:
> > It could also be that I was unlucky in my purchase of cheap USB disk
> > enclosures.  Which is why I was careful to relate my experience but
> > not cast blame.  Your experiences and others may very well be
> > different!  You will have different hardware at the least.  That
> > will make a big difference.  I encourage everyone to generate their
> > own experience and collect and report the data from it.  It is
> > obvious what I am thinking but that doesn't mean it is correct.  I
> > am simply communicating in what I hope to be a helpful way.

My experience has only recently shown that USB 3.0 disks are not that
reliable (compare
https://lists.debian.org/debian-user/2014/09/msg00602.html). Still I do
not know if this also applies to USB 2.0 disks. As far as I can tell,
much of the USB instability originates from the fact, that USB uses
extremly cheap cables and controllers to transfer data very quickly
which results in data being often corrupted. Using the ``slower'' USB
2.0, this problem arises less frequently.

> I also have a USB disk enclosure, in which sits a 3,5" IDE-ATAPI
> drive, encrypted with LUKS. It is a really cheap, no-name enclosure
> that I've had for years, and so far I have had no problems with it.

I'd be interested to know, if this is an USB 3.0 or USB 2.0 model,
because I think USB 2.0 is much more reliable (although also slower).

[...]

> That means I have to decide between eSATA and IEEE-1394 as interfaces.
> Only this machine has eSATA, I think, while both machines I might want
> to connect it to has Firewire. Which of these would be the best choice
> from a technical standpoint, and do they work well with Linux? I'd
> imagine eSATA would simply be seen as a SATA device?

Although I have never used eSATA or IEEE-1394, I'd generally recommend
eSATA because the internal SATA is not very different and works very
reliable here. Also, eSATA is much faster than IEEE-1394 and USB 2.0
(although minimally slower than USB 3.0, I'd still prefer eSATA for
reliability).

> Might it also be better to go with a little bit more expensive
> enclosure?

I wonder whether the quality of controllers and cables really depends
on the prices of the enclosure or if the higher price only accounts for
a trademarked or nicer design?

Btw: This is my first list-mail using Claws-Mail. I hope it arrives
just as usual :)

Linux-Fan

-- 
http://masysma.lima-city.de/


signature.asc
Description: PGP signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

On 20150403_1501-0600, Bob Proulx wrote:
> Paul E Condon wrote:
> > David Wright wrote:
> > > I'm not so unlucky as Bob appears to be (he says, touching wood), but
> > 
> > I think Bob came to his conclusion during a previous period of
> > instability in Debian,
> 
> It could also be that I was unlucky in my purchase of cheap USB disk
> enclosures.  Which is why I was careful to relate my experience but
> not cast blame.  Your experiences and others may very well be
> different!  You will have different hardware at the least.  That will
> make a big difference.  I encourage everyone to generate their own
> experience and collect and report the data from it.  It is obvious
> what I am thinking but that doesn't mean it is correct.  I am simply
> communicating in what I hope to be a helpful way.
> 
> Also I know the USB interface is terrible.  I have had the fortune not
> to need to develop on it directly but I have worked with others who
> have had to deal with it in great detail.  Everyone always says the
> same thing.  People who work at the low level USB always report that
> it is a terrible standard.  And yet it has arrived as the defacto
> interconnect used everywhere.  Sigh.  We are going to need to be using
> it for many years.
> 
> I do pause for thought when people talk about file system and usb
> problems "in Debian" as if Debian is the upstream for it.  For the
> most part this would be "in Linux" (unless one was a kfreebsd user).
> Although Debian does have patches for the Linux kernel as far as I can
> see every attempt is made to stick with upstream for the main
> functionality as much as possible.  No one wants to fork and maintain
> critical functionality such as this.  If I had read "a previous period
> of instability in Linux" I think that would have been more accurate.
> Yet the Debian Stable kernels have been selected versions of the Linux
> kernel selected for their stability.  And I had no other flakiness
> noticed.
> 
> That is why I blame my cheap hardware.  And I emphasize cheap because
> literally I can't remember spending more than $20 for any one of my
> USB disk enclosures.  It is a "Market for Lemons".
> 
>   http://en.wikipedia.org/wiki/The_Market_for_Lemons
> 
> > but rather than start an argument that can only degenerate trying to
> > score debating point, I want to gather more date.
> 
> I hope we have a pleasant discourse concerning it.  Out of the
> collected experience I hope we can deduce the best ways to deal with
> these problems.  Hopefully no arguments between us.
> 
> > Bob has already helped me by making a truly useful suggestion,
> > for which I thank him.
> 
> You are most welcome for the hints!  Small and insignificant though
> they may be.
> 
> Bob

Bob,
On rereading my message, I can see why you are unhappy and offended.

My intent in specifying Debian was to single it out as a place on the
web where rational and knowledgeable people are found, yourself
especially. 

Between making ill advised posts here, I have been searching the web.
I found two sources that I wish had known about, but didn't.

One is the Backblaze.com web site. Their marketing actually contains
some real technical information on modern HD technology.

And an article in Wikipedia on the history of disk storage:
(http://en.wikipedia.org/wiki/Hard_disk_drive) and other articles that
are linked from there. I learned things that you might think everyone
knows, but I didn't.

For instance, it is known that HDD failure rates do not have 'infant
mortality' (tendency to fail when first put into service) nor
'senility' (a tendency to fail late in life, after a long period of
reliable service).

And, the newer high information density drives all have a supply of
reserve sectors which they use to automatically replace sectors that
are showing signs of incipient failure.

All of the disks in USB packaging that I have had are ones for which
these facts apply. If one is gathering the right data while using
them, one can predictably when they cannot continue to serve, that is
when, for each disk individually, its supply of reserve sectors runs
out. Other random failures can shorten the life to something less can
cause failure when there is still a supply of 'reserve' sectors.

The technical basis of the Backblaze business monitoring all the spinning
reserve (which is a borrowed technical term from the electrical power
industry where it means a dynamo that is already spinning but is not
actually delivering power to the grid).

I certainly wasn't keeping records of HD performance the way Backblase
says they do. I am rethinking. I think I need to be quiet for awhile.

Best regards,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150404171055.gb17...@big.lan.gnu

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Jörg-Volker Peetz]

I remember similar problems with a USB drive which were due to a broken cable.
Did you check with another USB cable?
-- 
Regards,
jvp.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mfos28$i86$1...@ger.gmane.org

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Petter Adsen]

On Fri, 3 Apr 2015 15:01:26 -0600
Bob Proulx  wrote:
> It could also be that I was unlucky in my purchase of cheap USB disk
> enclosures.  Which is why I was careful to relate my experience but
> not cast blame.  Your experiences and others may very well be
> different!  You will have different hardware at the least.  That will
> make a big difference.  I encourage everyone to generate their own
> experience and collect and report the data from it.  It is obvious
> what I am thinking but that doesn't mean it is correct.  I am simply
> communicating in what I hope to be a helpful way.

I also have a USB disk enclosure, in which sits a 3,5" IDE-ATAPI drive,
encrypted with LUKS. It is a really cheap, no-name enclosure that I've
had for years, and so far I have had no problems with it.

Reading your previous mails make me a little worried, though. It is
only used as a sort of semi-online backup, that I connect when I run
the backup, but my main backups are on bluray-discs. Now I begin to
wonder if I should invest in another drive for backing up stuff, but I
would still want it to be removable.

That means I have to decide between eSATA and IEEE-1394 as interfaces.
Only this machine has eSATA, I think, while both machines I might want
to connect it to has Firewire. Which of these would be the best choice
from a technical standpoint, and do they work well with Linux? I'd
imagine eSATA would simply be seen as a SATA device?

Might it also be better to go with a little bit more expensive
enclosure?

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."


pgpGvPoPBbVTK.pgp
Description: OpenPGP digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

David Wright wrote:
> I must investigate nice/renice to prevent its taking over.

And also check out 'ionice' too in addition to nice/renice.  It is
useful in this problem space when dealing with I/O bandwidth and
priority.

And in the problem space of 'nice' there is another very interesting
program called 'loadwatch'.  It is pretty cool.

Bob

  man loadwatch

  NAME
   loadwatch - run a program when machine is idle

  SYNOPSIS
   loadwatch [options] -p pid | [--] prog [args]

  DESCRIPTION
   loadwatch either spawns a child process prog with the arguments
   args and controls it with all its process group, or takes
   control of an already running process with pid pid with all its
   process group.

   loadwatch allows the controlled processes to run while the load
   average remains below high_limit. Every delay seconds,
   loadwatch checks the load average. If the load is above
   high_limit, the child is suspended; the child is resumed when
   the load falls below low_limit.


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

Paul E Condon wrote:
> David Wright wrote:
> > I'm not so unlucky as Bob appears to be (he says, touching wood), but
> 
> I think Bob came to his conclusion during a previous period of
> instability in Debian,

It could also be that I was unlucky in my purchase of cheap USB disk
enclosures.  Which is why I was careful to relate my experience but
not cast blame.  Your experiences and others may very well be
different!  You will have different hardware at the least.  That will
make a big difference.  I encourage everyone to generate their own
experience and collect and report the data from it.  It is obvious
what I am thinking but that doesn't mean it is correct.  I am simply
communicating in what I hope to be a helpful way.

Also I know the USB interface is terrible.  I have had the fortune not
to need to develop on it directly but I have worked with others who
have had to deal with it in great detail.  Everyone always says the
same thing.  People who work at the low level USB always report that
it is a terrible standard.  And yet it has arrived as the defacto
interconnect used everywhere.  Sigh.  We are going to need to be using
it for many years.

I do pause for thought when people talk about file system and usb
problems "in Debian" as if Debian is the upstream for it.  For the
most part this would be "in Linux" (unless one was a kfreebsd user).
Although Debian does have patches for the Linux kernel as far as I can
see every attempt is made to stick with upstream for the main
functionality as much as possible.  No one wants to fork and maintain
critical functionality such as this.  If I had read "a previous period
of instability in Linux" I think that would have been more accurate.
Yet the Debian Stable kernels have been selected versions of the Linux
kernel selected for their stability.  And I had no other flakiness
noticed.

That is why I blame my cheap hardware.  And I emphasize cheap because
literally I can't remember spending more than $20 for any one of my
USB disk enclosures.  It is a "Market for Lemons".

  http://en.wikipedia.org/wiki/The_Market_for_Lemons

> but rather than start an argument that can only degenerate trying to
> score debating point, I want to gather more date.

I hope we have a pleasant discourse concerning it.  Out of the
collected experience I hope we can deduce the best ways to deal with
these problems.  Hopefully no arguments between us.

> Bob has already helped me by making a truly useful suggestion,
> for which I thank him.

You are most welcome for the hints!  Small and insignificant though
they may be.

Bob


signature.asc
Description: Digital signature

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[David Wright]

Quoting Paul E Condon (pecon...@mesanetworks.net):
> On 20150402_2135-0500, David Wright wrote:
> > I do get occasional I/O errors on USB transfers, which can make the
> > disk readonly, but sometimes make it disappear altogether (ie it
> > gets unmounted, not remounted).
> 
> All of my file systems are journaled. Did you notice a delay in remount
> as the journal was replayed?

No, but I wasn't watching for it. I will in future (though obviously
I have adjusted my working practice to minimise the rare occurrences).

> > Just in passing, if clamav wakes up and spots the USB drive, file
> 
> clamav is terra incognita to me. 

And not much more than that to me. I must investigate nice/renice
to prevent its taking over.

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150403134615.gb5...@alum.home

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

On 20150402_2135-0500, David Wright wrote:
> Quoting Paul E Condon (pecon...@mesanetworks.net):
> [...]
> > Some time ago I decided to a make a copy of these data,
> > so I would have more than one copy.
> [...]
> Is the copying between a USB disk and an internal, or between two
> partitions on the same USB disk, or between two USB disks? (Ranked in
> decreasing reliability in my own experience.)
> 
> > When I tried, the job would always crash well before completion.
> 
> What are the symptoms of a crash? (Hang, segfault, write-failure
> as readonly, etc)
  Switch of target disk to read-only mount.
> 
> [...]
> > But in both cases the
> > deletion failed because 'gfx2' has been remounted read-only, which
> > makes it impossible to update the target directory tree.
> 
> Do you watch /var/log/kern.log which this is going on. I find that
> quite useful. For example, messages like
> usb 1-8: reset high-speed USB device number 5 using ehci_hcd
> are accompanied by a pause of anything up to a minute in file
> transfer. I get these quite frequently if I do massive copies between
> two USB disks, so I now stage such copies through the internal disk.

Thanks. I do watch my own capture of the file descriptors 1 and 2 into
a file in /var/pec/ (sub-dir name, pec, is my initials). This will be
a useful addition, I'm sure.

In my system, most of my hypothesizing is from observing coincident
changes in two or more of the nine (soon to be ten) windows that I
monitor on system 'big'

> 
> I'm not so unlucky as Bob appears to be (he says, touching wood), but

I think Bob came to his conclusion during a previous period of
instability in Debian, but rather than start an argument that can only
degenerate trying to score debating point, I want to gather more
date. Bob has already helped me by making a truly useful suggestion,
for which I thank him.

It's getting late here. I won't get anything useful done tonight.
I'll just start making mistakes, if I start something new now.

May you both have a good night,
Paul

> I do get occasional I/O errors on USB transfers, which can make the
> disk readonly, but sometimes make it disappear altogether (ie it
> gets unmounted, not remounted).

All of my file systems are journaled. Did you notice a delay in remount
as the journal was replayed?

> > I have not tried it, but from my investigation I'm sure that a
> > massive delete of some obsolete file structure from the HD that
> > was /dev/sda1 during Debian install would trigger a remount-ro,
> > which surely would lead to a system crash in short order.
> 
> You get streams of error messages (like when the disk fills up)
> but it shouldn't actually crash.
> 
> (OTOH when you get a kernel error, there can be circumstances where
> the system will panic and *not* sync/write to the disk because to do
> so could cause corruption.)

So it helps to know about data that can be ignored for a legitimate
reason.

> [...]
> > I'm worried about what I found. I want to interest someone who has far
> > more knowledge about how the kernel actually works internally to look
> > into this. I done other experiments more complicated to report, I can't
> > find anything comforting about this situation. If you think it's OK,
> > you probably don't understand, IMHO.
> 
> My prejudices, based on no more than observations of my system, make me,
> like Bob, suspect the interface rather than the kernel. My wife,
> running windows, sees similar external symptoms (pauses, errors),
> though neither of us would know how to observe them in like manner to
> linux.

I like to play the scientist in my old age. All theories begin with curiosity
about a random observation. A classic case is the observation of a pocket
watch lieing on the path during a walk in a park. In our case of hypotheses
about the design of the kernel, it is unacceptable to me to invoke the idea
of a universal creator, and perfectly OK to contemplate the possibility of
a flaw in the design.

> Just in passing, if clamav wakes up and spots the USB drive, file

clamav is terra incognita to me. 

> transfers can stop for 10 or 15 minutes; the USB disk heads will still
> be very active. I keep an xterm running top so I can spot that (and
> other cpu-guzzlers like xulrunner).
> 
> Oh, and to David C, this happens irrespective of wheezy or jessie
> (for me).
> 
> Cheers,
> David.

Cheers, 

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150403053937.gf3...@big.lan.gnu

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

On 20150402_1746-0700, David Christensen wrote:
> On 04/02/2015 04:21 PM, Paul E Condon wrote:
> >For several years I have been making daily backups of my four Debian
> >computers using Rsync and a small script of my own devising. The data
> >has been accumulating on an external USB drive in a partition with the
> >label, gfx5. Some time ago I decided to a make a copy of these data,
> >so I would have more than one copy. I had to use Rsync to do this
> >because it I were to use cp the copies of files labeled by different
> >dates and hard-link together on gfx5 would exceed the capacity on the
> >target disk (which was/is labeled gfx2). This is a simple one line
> >command to Rsync.  When I tried, the job would always crash well
> >before completion.
> 
> You're using a "Testing" operating system distribution (Jessie), not a
> "Stable" operating system distribution (Wheezy):
> 
> 1.  If you want to help debug Jessie, then you should create a script that
> demonstrates the undesired behavior on a fresh install of a specific
> snapshot of Jessie and post your script and console session. (E.g. the
> script should not depend upon your data, systems, or networks; it should
> produce similar results on "equivalent" machines.)

  Until I discovered a pattern in failures, my default assumption was that
  the problems were inattention to detail on my part and frequent upgrades
  of Jessie, which can happen almost daily. Does someone have a stable of
  i386 computers each one with a particular weekly build on it? I don't.

>
> 2.  If you want reliable operations, then you should use Wheezy.  If that
> doesn't do what you want, post your console session.

I got into this thinking I want to follow Jessie development, and
tinker with a pet project while exercising Jessie to see if I could
notice any bugs. I don't want to be running Wheezy when Jessie is
released, and I don't want to explain openly why. The evidence that
made me write was gathered from nine windows of ssh sessions on 'gq'
being displayed on 'big'.  I would have to make a video 'movie' of the
nine together to show what I saw. I can't do that. I don't have the
knowledge, skill, or equipment.  It was gleaned for which windows
changed in coincidence, and which changed singly. If anyone does have
several computers that can be dedicated for a short while, and the
curiosity to see if my observations can be reproduced, I think it
would be nice if they would contact me for more details. I don't want
to write a great treatise that nobody will read or understand. I've
been criticized for the way I write.

The basic list is two computers, two USB hard disks 3TB or maybe
larger. The computer to which the 3TB disks are plugged in should have
12GB or more of swap space to accomodate Rsync of this big tranfer as
one go. (the Rsync options are -aHvv ).  And a copious source of
structured data (a local GIT server, perhaps) Maybe someone who knows
about Clouds could do the whold test with Clouds and virtualization,
about which I also know nothing practical.

> 
> 
> In either case, you will want to check the source and destination file
> systems before invoking 'rsync':
> 
> $ man fsck

  I know about man fsck. I have read it many times. I have already
  eliminated many hypotheses thru careful readings of man fsck. And
  careful examination of the source and destination file systems. 

I know how little chance I have of convincing this audience that I have
seen what I believe I have seen. Offering to help qualified people to
develop their own independent tests of my hypothesis is the way I want
to go. At some point this will be decided. If I'm right, I really won't
be happy, because it will be very bad for Debian. 

Best regards,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150403053855.ge3...@big.lan.gnu

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

On 20150402_1803-0600, Bob Proulx wrote:
> Paul E Condon wrote:
> > For several years I have been making daily backups of my four Debian
> > computers using Rsync and a small script of my own devising. The data
> > has been accumulating on an external USB drive in a partition with the
> >...
> > I'm worried about what I found. I want to interest someone who has far
> > more knowledge about how the kernel actually works internally to look
> > into this. I done other experiments more complicated to report, I can't
> > find anything comforting about this situation. If you think it's OK,
> > you probably don't understand, IMHO.
> 
> I often have problems with USB mounted file systems.  I believe the
> cheap nature of the USB hardware all around to be the major
> contributor.  I do use USB for "a big floppy" all of the time.  But
> whenever I keep a USB disk mounted for a long time it has always
> failed after a while.  A month.  Six months.  I find the USB file
> system subsystem unreliable.  I would never trust it for critical data
> such as backups.  I think you are seeing the same unreliable mounted
> USB disk problems that I have seen for a long time.
> 
> If you remove the disk from your USB container and mount it directly
> with its native SATA (or IDE) connector then you will find that it is
> as reliable as the rest of the native storage.  I blame the cheap USB
> controller electronics.  Although perhaps the kernel driver is also to
> blame in there too.
> 
> [On the converse I find USB network adapters and USB sound cards to
> have been rock solid.  Meaning that while I avoid USB disks I actively
> use USB networking on several machines to add additional NICs.  I am
> planning another site using additional USB NICs.  It is probably
> hardware dependent but they have been working great for me regardless
> of seeing the opposite for disks.  And I have three sites using USB
> sound cards very robustly.  Since I disparaged USB disk I felt I
> needed to clarify that it was only disk and not other USB.]
> 
> > I found two other ways to delay the crash:
> > 1) using nice as in: ' nice -n 19 find -depth -print -delete'
> >(this, I think, slows down the main running job in relation to the
> >running of the kernel.)
> 
> Read the man page for "ionice".  You might consider using it instead
> of nice.  Nice works with cpu usage.  But ionice works with I/O usage
> and is directly what you are fighting.  You might try:
> 
>   ionice -c 3 find -depth -print -delete

Thanks for this suggestion.

> 
> If I am deleting an entire file system I will usually simply mkfs on
> top and reset it to empty that way.  On a file system with millions of
> files that will be much faster than deleting them individually.
> Obviously only works if it is the entire file system.
> 
> Bob

About long term mounts of USB being a problem: On the same computer
there is mounted a USB labeled 'sgt1' which is a 1 TB external USB. It
is the disk that is currently collecting daily backups using the same
script as was mentioned in my first email. Day in, day out, if that
computer is on, cron takes a full backup a little before 630 AM and
sends an email to me if there is anything written to file descriptor
2.  There is nothing, unless investigation reveals a cause, like I
unplugged the power supply while vacuuming the area and forgot to plug
it back in.

I know you have had a different experience. I have been running this
script unchanged since before 2009 and only since I have been running
Jessie and running copies of massive file structure have I been having
problems.  The script uses the Rsync option --link-dest=DIR and really
a very small amount of data is actually transferred in each daily
run. Rsync regularly reports Speedup of over 1000 times. I had been
making quite a lot of progress on organizing these file in a more
useful way, until I made the decision to move to Jessie, for reasons
that I am sure will turn out to be justified.  For me, every failure
of an external USB HD turned out, after the fact to be attributable to
my not already knowing something like the transition to larger sector
size. I've learned a lot. And I don't want to imply that 'sgt1' has
been in service since 2009, just that one HD was connected to that
computer with its spindle motor running, and always responding wnen
crontab called for it.

So I'm skeptical. You may be right. But we are mostly all running Jessie,
now, and will all be running Jessie soon.

Thanks,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150403053739.gd3...@big.lan.gnu

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[David Wright]

Quoting Paul E Condon (pecon...@mesanetworks.net):
[...]
> Some time ago I decided to a make a copy of these data,
> so I would have more than one copy.
[...]
Is the copying between a USB disk and an internal, or between two
partitions on the same USB disk, or between two USB disks? (Ranked in
decreasing reliability in my own experience.)

> When I tried, the job would always crash well before completion.

What are the symptoms of a crash? (Hang, segfault, write-failure
as readonly, etc)

[...]
> But in both cases the
> deletion failed because 'gfx2' has been remounted read-only, which
> makes it impossible to update the target directory tree.

Do you watch /var/log/kern.log which this is going on. I find that
quite useful. For example, messages like
usb 1-8: reset high-speed USB device number 5 using ehci_hcd
are accompanied by a pause of anything up to a minute in file
transfer. I get these quite frequently if I do massive copies between
two USB disks, so I now stage such copies through the internal disk.

I'm not so unlucky as Bob appears to be (he says, touching wood), but
I do get occasional I/O errors on USB transfers, which can make the
disk readonly, but sometimes make it disappear altogether (ie it
gets unmounted, not remounted).

> I have not tried it, but from my investigation I'm sure that a
> massive delete of some obsolete file structure from the HD that
> was /dev/sda1 during Debian install would trigger a remount-ro,
> which surely would lead to a system crash in short order.

You get streams of error messages (like when the disk fills up)
but it shouldn't actually crash.

(OTOH when you get a kernel error, there can be circumstances where
the system will panic and *not* sync/write to the disk because to do
so could cause corruption.)

[...]
> I'm worried about what I found. I want to interest someone who has far
> more knowledge about how the kernel actually works internally to look
> into this. I done other experiments more complicated to report, I can't
> find anything comforting about this situation. If you think it's OK,
> you probably don't understand, IMHO.

My prejudices, based on no more than observations of my system, make me,
like Bob, suspect the interface rather than the kernel. My wife,
running windows, sees similar external symptoms (pauses, errors),
though neither of us would know how to observe them in like manner to
linux.

Just in passing, if clamav wakes up and spots the USB drive, file
transfers can stop for 10 or 15 minutes; the USB disk heads will still
be very active. I keep an xterm running top so I can spot that (and
other cpu-guzzlers like xulrunner).

Oh, and to David C, this happens irrespective of wheezy or jessie
(for me).

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150403023548.ga17...@alum.home

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[David Christensen]

On 04/02/2015 04:21 PM, Paul E Condon wrote:

For several years I have been making daily backups of my four Debian
computers using Rsync and a small script of my own devising. The data
has been accumulating on an external USB drive in a partition with the
label, gfx5. Some time ago I decided to a make a copy of these data,
so I would have more than one copy. I had to use Rsync to do this
because it I were to use cp the copies of files labeled by different
dates and hard-link together on gfx5 would exceed the capacity on the
target disk (which was/is labeled gfx2). This is a simple one line
command to Rsync.  When I tried, the job would always crash well
before completion.


You're using a "Testing" operating system distribution (Jessie), not a 
"Stable" operating system distribution (Wheezy):


1.  If you want to help debug Jessie, then you should create a script 
that demonstrates the undesired behavior on a fresh install of a 
specific snapshot of Jessie and post your script and console session. 
(E.g. the script should not depend upon your data, systems, or networks; 
it should produce similar results on "equivalent" machines.)


2.  If you want reliable operations, then you should use Wheezy.  If 
that doesn't do what you want, post your console session.



In either case, you will want to check the source and destination file 
systems before invoking 'rsync':


$ man fsck


HTH,

David


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/551de2d3.4050...@holgerdanske.com

Re: A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Bob Proulx]

Paul E Condon wrote:
> For several years I have been making daily backups of my four Debian
> computers using Rsync and a small script of my own devising. The data
> has been accumulating on an external USB drive in a partition with the
>...
> I'm worried about what I found. I want to interest someone who has far
> more knowledge about how the kernel actually works internally to look
> into this. I done other experiments more complicated to report, I can't
> find anything comforting about this situation. If you think it's OK,
> you probably don't understand, IMHO.

I often have problems with USB mounted file systems.  I believe the
cheap nature of the USB hardware all around to be the major
contributor.  I do use USB for "a big floppy" all of the time.  But
whenever I keep a USB disk mounted for a long time it has always
failed after a while.  A month.  Six months.  I find the USB file
system subsystem unreliable.  I would never trust it for critical data
such as backups.  I think you are seeing the same unreliable mounted
USB disk problems that I have seen for a long time.

If you remove the disk from your USB container and mount it directly
with its native SATA (or IDE) connector then you will find that it is
as reliable as the rest of the native storage.  I blame the cheap USB
controller electronics.  Although perhaps the kernel driver is also to
blame in there too.

[On the converse I find USB network adapters and USB sound cards to
have been rock solid.  Meaning that while I avoid USB disks I actively
use USB networking on several machines to add additional NICs.  I am
planning another site using additional USB NICs.  It is probably
hardware dependent but they have been working great for me regardless
of seeing the opposite for disks.  And I have three sites using USB
sound cards very robustly.  Since I disparaged USB disk I felt I
needed to clarify that it was only disk and not other USB.]

> I found two other ways to delay the crash:
> 1) using nice as in: ' nice -n 19 find -depth -print -delete'
>(this, I think, slows down the main running job in relation to the
>running of the kernel.)

Read the man page for "ionice".  You might consider using it instead
of nice.  Nice works with cpu usage.  But ionice works with I/O usage
and is directly what you are fighting.  You might try:

  ionice -c 3 find -depth -print -delete

If I am deleting an entire file system I will usually simply mkfs on
top and reset it to empty that way.  On a file system with millions of
files that will be much faster than deleting them individually.
Obviously only works if it is the entire file system.

Bob


signature.asc
Description: Digital signature

A question about deleting a big file structure from a big disk in Jessie: Why does this work? I'm really worried.

[Paul E Condon]

For several years I have been making daily backups of my four Debian
computers using Rsync and a small script of my own devising. The data
has been accumulating on an external USB drive in a partition with the
label, gfx5. Some time ago I decided to a make a copy of these data,
so I would have more than one copy. I had to use Rsync to do this
because it I were to use cp the copies of files labeled by different
dates and hard-link together on gfx5 would exceed the capacity on the
target disk (which was/is labeled gfx2). This is a simple one line
command to Rsync.  When I tried, the job would always crash well
before completion. Sometimes, a simple repeat invocation would make
further progress, sometimes not. I became curious. As I tried
different variations of how to observe the progress of transfer as it
happened, I acquired copies of failed transfers, and then discovered
that I could not reliably delete a failed copy by using the obvious,
'rm -rfv ... '
I discovered that the command 'find -depth -print -delete'
sometimes worked when 'rm -rfv ...' did not. But in both cases the
deletion failed because 'gfx2' has been remounted read-only, which
makes it impossible to update the target directory tree.

I have not tried it, but from my investigation I'm sure that a
massive delete of some obsolete file structure from the HD that
was /dev/sda1 during Debian install would trigger a remount-ro,
which surely would lead to a system crash in short order.

I investigated further. These investigations were done on a computer
which I call 'gq'. I set up experiments on 'gq' by using ssh to issue
commands in 'gq' from my main desktop computer, 'big'. I set up several
ssh windows into 'gq'. My first discovery was that after a crash while
attempting to delete with 'find -depth -print -delete ', there was a
long delay in remounting 'gfx2' while the mount command emptied the
journal (ext4) on 'gfx2'.

Next I tried 'find -depth -print -delete ', with some extra windows into
'gq' in which I issued the command 'sync'. The return from 'sync' was
delayed, sometimes as much as a minute, and if I didn't issue 'sync'
commands frequently enough, there was never a return from 'sync', just
the crash of the 'find' command. So frequent sync commands delayed the
crash.

I found two other ways to delay the crash:
1) using nice as in: ' nice -n 19 find -depth -print -delete'
   (this, I think, slows down the main running job in relation to the
   running of the kernel.)
2) using cntrl-Z to pause the 'find' job for a while
   (which I think also allows the kernel to catch up with the journal)
   I could also monitor the progress of the journal run, by issuing a
   sync command in a separate ssh window. 

I'm worried about what I found. I want to interest someone who has far
more knowledge about how the kernel actually works internally to look
into this. I done other experiments more complicated to report, I can't
find anything comforting about this situation. If you think it's OK,
you probably don't understand, IMHO.

Kind regards,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150402232106.gb3...@big.lan.gnu

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Hendrik Boom]

On Sat, 03 Aug 2013 16:29:06 -0500, Selim T. Erdogan wrote:

> Hendrik Boom,  3.08.2013:
>> 
>> Every other program on my laptop finds the right IP number for
>> slashdot.
>> It's just Chromium that doesn't.  Even Chrome gets it right.  Somewhere
>> Chromium has hidden state I can't expunge.
> 
> You could try purging the package ("apt-get remove --purge ...") and get
> rid of all not-user-specific state.  And then you could install again
> and see if the problem persists.  I don't use chromium much but
> *presumably* your bookmarks and other info you'd like to keep are stored
> in your home directory and will live through the purge.

Good idea.

On Sun, 04 Aug 2013 10:12:34 +, Curt wrote:

> On 2013-08-03, Hendrik Boom  wrote:
>>
>> And if the secret bit of state I can't expunge ends up getting synced
>> along with the bookmarks, things may get worse instead of better.
> 
> You moved (I haven't been following the thread) the '~/.config/chromium'
> directory out of the way already ('mv chromium chromium.bak' or whatever
> to see whether the bug was hiding in there somewhere)?

Good idea.  And less drastic.

This suggests the even loss drastic test of logging in as a different 
user and seeing if they have the problem.  There is a guest account on 
the laptop, for example.

Thanks.

-- hendrik




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kts7jq$7i0$1...@ger.gmane.org

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Curt]

On 2013-08-03, Hendrik Boom  wrote:
>
> And if the secret bit of state I can't expunge ends up getting synced 
> along with the bookmarks, things may get worse instead of better.

You moved (I haven't been following the thread) the '~/.config/chromium'
directory out of the way already ('mv chromium chromium.bak' or whatever
to see whether the bug was hiding in there somewhere)?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkvsa9e.21u.cu...@einstein.electron.org

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Selim T. Erdogan]

Hendrik Boom,  3.08.2013:
> 
> Every other program on my laptop finds the right IP number for slashdot.  
> It's just Chromium that doesn't.  Even Chrome gets it right.  Somewhere  
> Chromium has hidden state I can't expunge.

You could try purging the package ("apt-get remove --purge ...") and 
get rid of all not-user-specific state.  And then you could install 
again and see if the problem persists.  I don't use chromium much but 
*presumably* your bookmarks and other info you'd like to keep are stored 
in your home directory and will live through the purge.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130803212906.ga20...@cs.utexas.edu

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Hendrik Boom]

On Fri, 19 Jul 2013 06:45:26 -0400, Stephen Allen wrote:

> On Thu, Jul 18, 2013 at 04:43:07PM +, Hendrik Boom wrote:
>> It's been most of a week now, and the problem persists.
>> Chromium still insists on going to the website normally known as
>> topoi.pooq.com when I request slashdot.org.
>> 
>> Neither iceweasel nor chrome do this; both find the proper
>> slashdot.org.
>> 
>> Even ping finds the proper site.
>> 
>> The problem presumably started a week ago when there was a temporary
>> networking problem, but only chromium seems to have fixated on the
>> wrong IP address.
>> 
>> I have followed the procedure for clearing chromium's dns cache.  When
>> I look at the cache contents, slashdot isn't in it.  Does chromium have
>> another, secret cache?
>> 
>> And it appears that I do not have nscd running, or even installed.
>>  
>> I'm starting to think of shuttering chromium forever, assuming I can
>> copy its bookmarks elsewhere, say, to chrome.
>> 
>> 
> ---end quoted text---
> 
> Why would you need to copy your bookmarks? Presumably you used bookmark
> sync with Chromium, thus they will be available to Google-Chrome when
> you login into your Google account the 1st time in Chrome.

I'm using both Chromium and Chrome.  It's not entirely clear to me that 
sync will merge the two sets of bookmarks instead of having one set 
clobber the other.

> 
> Have you tried using a different DNS server? Try the Google DNS servers,
> Google will give you their address -- I don't have them handy at the
> moment.

I am already using the Google DNS servers.  The DHCP server on my LAN 
tells all my machines to use Google's DNS servers.

Every other program on my laptop finds the right IP number for slashdot.  
It's just Chromium that doesn't.  Even Chrome gets it right.  Somewhere  
Chromium has hidden state I can't expunge.

And if the secret bit of state I can't expunge ends up getting synced 
along with the bookmarks, things may get worse instead of better.

-- hendrik.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ktj2of$5uo$1...@ger.gmane.org

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Paul Cartwright]

  
  
 




  ---end quoted text---

Why would you need to copy your bookmarks? Presumably you used bookmark
sync with Chromium, thus they will be available to Google-Chrome when
you login into your Google account the 1st time in Chrome.

Have you tried using a different DNS server? Try the Google DNS servers,
Google will give you their address -- I don't have them handy at the
moment.





  8.8.8.8
  8.8.4.4



-- 
Paul Cartwright
  



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e934a1.6060...@gmail.com

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Stephen Allen]

On Thu, Jul 18, 2013 at 04:43:07PM +, Hendrik Boom wrote:
> On Sun, 14 Jul 2013 14:57:14 +, Hendrik Boom wrote:
> 
> > On Sat, 13 Jul 2013 16:53:01 -0400, staticsafe wrote:
> > 
> >> On Sat, Jul 13, 2013 at 08:39:10PM +, Hendrik Boom wrote:
> >>> For some reason, chromium seems to have got it stuck in its head that
> >>> slashdot,org is at 69.165.131.134.  At least, when I try to browse to
> >>> slashdot.org using chromium, the displayed contents are identical to
> >>> the contents at 16.165.131.134, which contains my personal web site.
> >>> 
> >>> Firefox and chrome have no trouble reaching the real site.
> >>> 
> >>> And I can read slashdot just fine on chromium if I enter the IP number
> >>> 216.34.181.45 instead of the domain name.
> >>> 
> >>> So I'm guessing that chromium has got that IP number stuck in some
> >>> internal DNS cache.
> > 
> > It now looks as if chromium's DNS cache may not be the problem. 
> > Chromium must be getting slashdot's IP address from somewhere else --
> > somewhere that firefox and ping don't access.
> > 
> > 
> >>> How can I get it to forget it?
> >>> 
> >>> -- hendrik
> >> 
> >> Navigate to chrome://net-internals/#dns and press the "Clear host
> >> cache"
> >> button.
> > 
> > After navigating there from chromium and pressing the button,
> > slashdot.org doesn't appear in the listing of the cache entries on that
> > page.
> > 
> > But the misbehaviour still persists, even after a reboot.
> > 
> > And firefox and chrome and ping still reach the right site.
> > 
> > And when I go to chrome://net-internals/#dns on chrome itself, it tells
> > mem it *does* have slashdot.org in its cache, with the right IP number.
> > 
> > The cache chromium reveals with chrome://net-internals/#dns clearly has
> > different contents from the one that chrome reveals -- which confirms
> > that they have different caches.
> > 
> > And even after browsing to slashdot.org in chromium and getting to the
> > wrong place, going to chrome://net-internals/#dns with chromium still
> > indicates that slashdot.org is not in the cache.
> > 
> > So I'm suspecting that chrome://net-internals/#dns may not reeveal the
> > real cache in chromium.
> > 
> > So where *is* chromium getting this misinformation?
> > 
> > Just for reference, here's my /etc/resolv.conf file:
> > 
> > # Generated by NetworkManager domain topoi.pooq.com search
> > topoi.pooq.com nameserver 8.8.8.8 nameserver 8.8.4.4
> > 
> > 
> > -- hendrik
> > 
> > 
> >> Source -
> >> http://superuser.com/a/203702
> 
> It's been most of a week now, and the problem persists.
> Chromium still insists on going to the website normally known as 
> topoi.pooq.com when I request slashdot.org.
> 
> Neither iceweasel nor chrome do this; both find the proper slashdot.org.
> 
> Even ping finds the proper site.
> 
> The problem presumably started a week ago when there was a temporary 
> networking problem, but only chromium seems to have fixated on the wrong 
> IP address.
> 
> I have followed the procedure for clearing chromium's dns cache.  When I 
> look at the cache contents, slashdot isn't in it.  Does chromium have 
> another, secret cache?
> 
> And it appears that I do not have nscd running, or even installed.
>  
> I'm starting to think of shuttering chromium forever, assuming I can copy 
> its bookmarks elsewhere, say, to chrome.
> 
> 
---end quoted text---

Why would you need to copy your bookmarks? Presumably you used bookmark
sync with Chromium, thus they will be available to Google-Chrome when
you login into your Google account the 1st time in Chrome.

Have you tried using a different DNS server? Try the Google DNS servers,
Google will give you their address -- I don't have them handy at the
moment.

-- 
Cheers,
Stephen, Toronto
My Google+ Profile | http://goo.gl/JbQsq


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130719104526.ga4...@thunkpad.gateway.2wire.net

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Hendrik Boom]

On Sun, 14 Jul 2013 14:57:14 +, Hendrik Boom wrote:

> On Sat, 13 Jul 2013 16:53:01 -0400, staticsafe wrote:
> 
>> On Sat, Jul 13, 2013 at 08:39:10PM +, Hendrik Boom wrote:
>>> For some reason, chromium seems to have got it stuck in its head that
>>> slashdot,org is at 69.165.131.134.  At least, when I try to browse to
>>> slashdot.org using chromium, the displayed contents are identical to
>>> the contents at 16.165.131.134, which contains my personal web site.
>>> 
>>> Firefox and chrome have no trouble reaching the real site.
>>> 
>>> And I can read slashdot just fine on chromium if I enter the IP number
>>> 216.34.181.45 instead of the domain name.
>>> 
>>> So I'm guessing that chromium has got that IP number stuck in some
>>> internal DNS cache.
> 
> It now looks as if chromium's DNS cache may not be the problem. 
> Chromium must be getting slashdot's IP address from somewhere else --
> somewhere that firefox and ping don't access.
> 
> 
>>> How can I get it to forget it?
>>> 
>>> -- hendrik
>> 
>> Navigate to chrome://net-internals/#dns and press the "Clear host
>> cache"
>> button.
> 
> After navigating there from chromium and pressing the button,
> slashdot.org doesn't appear in the listing of the cache entries on that
> page.
> 
> But the misbehaviour still persists, even after a reboot.
> 
> And firefox and chrome and ping still reach the right site.
> 
> And when I go to chrome://net-internals/#dns on chrome itself, it tells
> mem it *does* have slashdot.org in its cache, with the right IP number.
> 
> The cache chromium reveals with chrome://net-internals/#dns clearly has
> different contents from the one that chrome reveals -- which confirms
> that they have different caches.
> 
> And even after browsing to slashdot.org in chromium and getting to the
> wrong place, going to chrome://net-internals/#dns with chromium still
> indicates that slashdot.org is not in the cache.
> 
> So I'm suspecting that chrome://net-internals/#dns may not reeveal the
> real cache in chromium.
> 
> So where *is* chromium getting this misinformation?
> 
> Just for reference, here's my /etc/resolv.conf file:
> 
> # Generated by NetworkManager domain topoi.pooq.com search
> topoi.pooq.com nameserver 8.8.8.8 nameserver 8.8.4.4
> 
> 
> -- hendrik
> 
> 
>> Source -
>> http://superuser.com/a/203702

It's been most of a week now, and the problem persists.
Chromium still insists on going to the website normally known as 
topoi.pooq.com when I request slashdot.org.

Neither iceweasel nor chrome do this; both find the proper slashdot.org.

Even ping finds the proper site.

The problem presumably started a week ago when there was a temporary 
networking problem, but only chromium seems to have fixated on the wrong 
IP address.

I have followed the procedure for clearing chromium's dns cache.  When I 
look at the cache contents, slashdot isn't in it.  Does chromium have 
another, secret cache?

And it appears that I do not have nscd running, or even installed.
 
I'm starting to think of shuttering chromium forever, assuming I can copy 
its bookmarks elsewhere, say, to chrome.

-- hendrik




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ks95ur$mvr$1...@ger.gmane.org

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Igor Cicimov]

Do you have nscd running by any chance?
 On 15/07/2013 12:58 AM, "Hendrik Boom"  wrote:

> On Sat, 13 Jul 2013 16:53:01 -0400, staticsafe wrote:
>
> > On Sat, Jul 13, 2013 at 08:39:10PM +, Hendrik Boom wrote:
> >> For some reason, chromium seems to have got it stuck in its head that
> >> slashdot,org is at 69.165.131.134.  At least, when I try to browse to
> >> slashdot.org using chromium, the displayed contents are identical to
> >> the contents at 16.165.131.134, which contains my personal web site.
> >>
> >> Firefox and chrome have no trouble reaching the real site.
> >>
> >> And I can read slashdot just fine on chromium if I enter the IP number
> >> 216.34.181.45 instead of the domain name.
> >>
> >> So I'm guessing that chromium has got that IP number stuck in some
> >> internal DNS cache.
>
> It now looks as if chromium's DNS cache may not be the problem.  Chromium
> must be getting slashdot's IP address from somewhere else -- somewhere
> that firefox and ping don't access.
>
> >>
> >> How can I get it to forget it?
> >>
> >> -- hendrik
> >
> > Navigate to chrome://net-internals/#dns and press the "Clear host cache"
> > button.
>
> After navigating there from chromium and pressing the button, slashdot.org
> doesn't appear in the listing of the cache entries on that page.
>
> But the misbehaviour still persists, even after a reboot.
>
> And firefox and chrome and ping still reach the right site.
>
> And when I go to chrome://net-internals/#dns on chrome itself, it tells
> mem it *does* have slashdot.org in its cache, with the right IP number.
>
> The cache chromium reveals with chrome://net-internals/#dns clearly has
> different contents from the one that chrome reveals -- which confirms
> that they have different caches.
>
> And even after browsing to slashdot.org in chromium and getting to the
> wrong place, going to chrome://net-internals/#dns with chromium still
> indicates that slashdot.org is not in the cache.
>
> So I'm suspecting that chrome://net-internals/#dns may not reeveal the
> real cache in chromium.
>
> So where *is* chromium getting this misinformation?
>
> Just for reference, here's my /etc/resolv.conf file:
>
> # Generated by NetworkManager
> domain topoi.pooq.com
> search topoi.pooq.com
> nameserver 8.8.8.8
> nameserver 8.8.4.4
>
>
> -- hendrik
>
> >
> > Source -
> > http://superuser.com/a/203702
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/krue89$l0o$1...@ger.gmane.org
>
>

Re: Deleting chromium DNS cache entry doesn't seem to help.

[Hendrik Boom]

On Sat, 13 Jul 2013 16:53:01 -0400, staticsafe wrote:

> On Sat, Jul 13, 2013 at 08:39:10PM +, Hendrik Boom wrote:
>> For some reason, chromium seems to have got it stuck in its head that
>> slashdot,org is at 69.165.131.134.  At least, when I try to browse to
>> slashdot.org using chromium, the displayed contents are identical to
>> the contents at 16.165.131.134, which contains my personal web site.
>> 
>> Firefox and chrome have no trouble reaching the real site.
>> 
>> And I can read slashdot just fine on chromium if I enter the IP number
>> 216.34.181.45 instead of the domain name.
>> 
>> So I'm guessing that chromium has got that IP number stuck in some
>> internal DNS cache.

It now looks as if chromium's DNS cache may not be the problem.  Chromium 
must be getting slashdot's IP address from somewhere else -- somewhere 
that firefox and ping don't access.

>> 
>> How can I get it to forget it?
>> 
>> -- hendrik
> 
> Navigate to chrome://net-internals/#dns and press the "Clear host cache"
> button.

After navigating there from chromium and pressing the button, slashdot.org 
doesn't appear in the listing of the cache entries on that page.

But the misbehaviour still persists, even after a reboot.

And firefox and chrome and ping still reach the right site.

And when I go to chrome://net-internals/#dns on chrome itself, it tells 
mem it *does* have slashdot.org in its cache, with the right IP number.

The cache chromium reveals with chrome://net-internals/#dns clearly has 
different contents from the one that chrome reveals -- which confirms 
that they have different caches.

And even after browsing to slashdot.org in chromium and getting to the 
wrong place, going to chrome://net-internals/#dns with chromium still 
indicates that slashdot.org is not in the cache.

So I'm suspecting that chrome://net-internals/#dns may not reeveal the 
real cache in chromium.

So where *is* chromium getting this misinformation?

Just for reference, here's my /etc/resolv.conf file:

# Generated by NetworkManager
domain topoi.pooq.com
search topoi.pooq.com
nameserver 8.8.8.8
nameserver 8.8.4.4


-- hendrik

> 
> Source -
> http://superuser.com/a/203702



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/krue89$l0o$1...@ger.gmane.org