Re: Bug: updating Debian9 not "allowed".

[Joerg Desch]

Am Thu, 26 Oct 2017 13:13:57 +0100 schrieb Darac Marjal:

> [Aside: The debian packaging tool is called "synaptic". "Synaptics" are
> a company producing touchpads. The two are not related]

I know, but I always make this mistake. ;-)

> I believe this is a known bug in synaptic: #864640 [1].

It is hard to believe that this bug is known since June and that there is 
neither a fix nor a solution. Deleting the file has worked for me, but I 
can't say that there are no side effects.

How should a newbie solve this? Without a work-around there are no 
updates possible.

Re: The new normal of logging

[Gene Heskett]

On Thursday 26 October 2017 21:21:37 Ben Caradoc-Davies wrote:

> On 27/10/17 13:02, Gene Heskett wrote:
> > On Thursday 26 October 2017 15:22:35 Nicholas Geovanis wrote:
> >> " And there's also systemd, that is slowly phagocytosing the UNIX
> >> part of Linux"
> >
> > I'm old enough to have taken phonics in grade school, but that
> > obviously invented word could probably be replaced by a 4 letter
> > adjective...
>
> Invented, yes, but over 130 years ago. The term phagocyte was coined
> in about 1883 by Carl Friedrich Wilhelm Claus to describe the cells
> discovered by Ilya Mechnikov, winner of the 1908 Nobel Prize in
> Medicine: https://en.wikipedia.org/wiki/Carl_Friedrich_Wilhelm_Claus
> https://en.wikipedia.org/wiki/Élie_Metchnikoff
> https://www.nobelprize.org/nobel_prizes/medicine/laureates/1908/
> https://www.nobelprize.org/nobel_prizes/medicine/laureates/1908/mechni
>kov-bio.html https://en.wikipedia.org/wiki/Phagocyte
> https://en.wikipedia.org/wiki/Phagocytosis
>
> And you would need a verb in the present tense, not an adjective, so
> probably more than four letters.
>
I agree.  And obviously you have more educational credits hanging on the 
wall than I.  My interest in the physical world did not include such 
early medicinal work, I had more interest in such things as capacitors 
and resistors, and am quite comfortable making vacuum tubes, or smart 
sand, do usefull work.

But my formal was terminated at my freshman year in high school by a 
health problem, which when the cause, then several years into my working 
life, an allergy to milk! So stopping that was a huge help. But by then 
it was a bit late to attempt going back to high school, so I kept on 
covering the service benches for electronics related stuff. Eventually 
migrated to  broadcasting, and put in about 25 years occupying the Chief 
Engineers office, last 18 of that as the CE at WDTV here in West 
Virginia, USA. I have been accused of walking on water electronically so 
these days, when I am purchaseing parts to make whatever and they want a 
business name, I am WOWElectronics.

Along the way to 83 yo, I did collect other papers to hang on the wall, 
like a 1st Phone (never cracked a book, walked in cold) and a C.E.T. 
(ditto). Then my new wife, back in '89, has a Bachelors in Music, so she 
had me go take the GED. Didn't hear for 3 weeks, I ran into the test 
administrator at the P.O. one morning & asked about it.  His reply 
was "why do you care? You were just doing it for the exercise, weren't 
you?" But I got it in the mail a couple days later.  And I have a 
Diploma from the University of Hard Knocks, an honorary from the wife's 
alma mater.

Its been quite a ride, all these years.  Some sad parts of course, but 
impressing the frogs, carving pricy wood or making a machine run by 
linuxcnc, and now caring for that wife in the last year that COPD might 
yet give her, all combines to keep me out of the bars.

You do what you have to do...

> Kind regards,

To you too, Ben Caradoc-Davies.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Serial Ports and Perl

[Richard Hector]

On 27/10/17 15:38, Martin McCormick wrote:
>   A perldoc of Device::SerialPort says that lookfor is
> supposed to block or hold until a character string emerges from
> the port as in /dev/ttyUSB0 or /dev/ttyS1.  When I trace the
> code, it just loops as fast as it can and never holds to wait for
> anything.

From my reading, if you call lookfor without any arguments, it will not
block, but poll the device and return immediately. Examples using that
behaviour have a sleep to stop it running away.

If you want the blocking behaviour, give it the number of characters
you're waiting for, and it will return only when it gets them.

I'm looking at

http://search.cpan.org/~cook/Device-SerialPort/1.04/SerialPort.pm#Methods_for_I/O_Processing

Richard



signature.asc
Description: OpenPGP digital signature

Re: estamated number of Linux users?

[Anthony DeRobertis]

On 10/26/2017 09:38 PM, Karen Lewellen wrote:

Hi all,
Any place where this number exists?  I would include those companies 
and web professionals, using Linux servers as apart of their craft?


This isn't an easy question to answer, or probably even a meaningful 
one, especially because it's easy to be a Linux user without knowing it. 
E.g., most consumer WiFi routers run Linux. Android phones & tablets run 
Linux. Chromebooks run Linux. A lot of set-top boxes run Linux. That's 
several billion Linux users from those alone.


You'll have even more issues determining what it means to say a company 
use Linux.


Once you've figured out what you mean by a "Linux user", there are 
probably some estimates, of varying quality using various methodologies.

Re: estamated number of Linux users?

[John Hasler]

Celejar writes:
> https://www.linuxcounter.net/
> I don't know how meaningful its data are.

Utterly useless.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Serial Ports and Perl

[Martin McCormick]

Andy Smith  writes:
> Hi Martin,

> I have been using it successfully for a long time, but all I do is
> read whole lines from the serial device like:
> 
> my $dev  = '/dev/ttyUSB0';
> my $port = Device::SerialPort->new($dev);
> 
> $port->baudrate(57600);
> $port->write_settings;
> 
> open my $fh, '<', $dev or die "Can't open $dev: $!";
> 

> while (<$fh>) {
> print "READ: $_\n";
> }
> 
> So, I am only using Device::SerialPort to configure the device,
> while all reading is done by treating it as a normal file.
> 
> I see you are using lookfor(), which I have never used before. From
> a brief look at:
> 
> 
> http://search.cpan.org/~cook/Device-SerialPort-1.002/SerialPort.pm#Methods_for_I/O_Processing
> 
> it seems you should be setting are_match() if you want lookfor() to
> match anything.
> 
> Cheers,
> Andy

I think I am going to call it a day and jump back on it in the
morning but opening the device is something I failed to do.  A
whole new rabit hole to go down and I wouldn't be surprised if
that wasn't the problem all along.

A perldoc of Device::SerialPort says that lookfor is
supposed to block or hold until a character string emerges from
the port as in /dev/ttyUSB0 or /dev/ttyS1.  When I trace the
code, it just loops as fast as it can and never holds to wait for
anything.  I thought this was strange and if I should have opened
the device, this may explain all the weirdness.  One of the
examples I saw did have a close statement on the device.  I bet I
just missed the need to open a file handle.

Thanks.  I'll post a message if that worked.

Martin McCormick

Re: estamated number of Linux users?

[Celejar]

On Thu, 26 Oct 2017 21:38:15 -0400 (EDT)
Karen Lewellen  wrote:

> Hi all,
> Any place where this number exists?  I would include those companies and 
> web professionals, using Linux servers as apart of their craft?

https://www.linuxcounter.net/

I don't know how meaningful its data are.

> Thanks,
> Karen

Celejar

Re: Serial Ports and Perl

[Fred]

On 10/26/2017 05:37 PM, Martin McCormick wrote:

The perl list I subscribe to seems to be on the fritz or I would
take the question there.  I want to write code that receives from
a RS-232 port and I just can't seem to get it to do anything.

The port I am reading is connected to a scanner radio and
produces generally short lines of text such as CD13, - or +, each
followed by a carriage return so these data should be very easy
to read.

If I use the kermit program, I do see the data when the
radio receives a signal but if I run the following script which
should hold and wait for some data, it holds and waits forever
even when data are present

#!/usr/bin/perl -w
use strict;
use Device::SerialPort;

sub comm {#serialport

my $port = Device::SerialPort->new("/dev/ttyUSB0");
$port->baudrate(9600); # Configure this to match your device
$port->databits(8);
$port->parity("none");
$port->stopbits(1);
$port->handshake("none");
$port->write_settings;
#This is supposed to flush the buffers.
$port->lookclear;
#This causes an infinite loop so it should hang and receive
#characters.
while (1) {
my $char = $port->lookfor;
#When there is nothing, go back and keep retrying.
 if ($char) {
print "$char\n";
}
}
return;
}#serial port

#Call the subroutine.

comm;

If this was working, it would show a column of all the
ASCII characters being received.  /dev/ttyUSB0 is a valid device
and works when used with kermit or even a C program I wrote.

If anybody has gotten the perl Device::SerialPort to
work, I am interested to know what I am doing or not doing.

Thank you for any constructive ideas.

Martin McCormick  WB5AGZ


Some years ago I used Perl for driving a pen plotter and I believe I 
used it for some input function also.  Unix considers devices to be more 
or less the same as files so the serial port was accessed the same as a 
file would be.


$port = "/dev/sts/ttyp02";
open (PLOTTER,">$port")  || die "something or other:$!\n";
This would open it for writing.  You are using "sane" parameters that 
serial ports default to so you wouldn't need to specify them.

Best regards,
Fred Boatwright

Re: The new normal of logging

[Joe Pfeiffer]

Gene Heskett  writes:

> On Thursday 26 October 2017 15:22:35 Nicholas Geovanis wrote:
>
>> On Thu, Oct 26, 2017 at 1:46 PM, Jonathan de Boyne Pollard <
>>
>> j.deboynepollard-newsgro...@ntlworld.com> wrote:
>> > Roberto C. Sánchez:
>> >
>> > Is this the new normal, for things to get captured in some systemd
>> > log
>> >
>> >> [...]?
>> >>
>> >> * https://unix.stackexchange.com/a/294206/5132 Yes.
>>
>> Thanks for that. And quoting that article
>> " And there's also systemd, that is slowly phagocytosing the UNIX part
>> of Linux"
>>
>> :-D
>
> I'm old enough to have taken phonics in grade school, but that obviously 
> invented word could probably be replaced by a 4 letter adjective...

You got me curious -- apparently phagocytosis was named in 1880.  But
yes, systemd seems to be attempting to subsume all other daemons, and is
pretty worrying for that reason...

Re: Serial Ports and Perl

[Henning Follmann]

On Thu, Oct 26, 2017 at 07:37:07PM -0500, Martin McCormick wrote:
> The perl list I subscribe to seems to be on the fritz or I would
> take the question there.  I want to write code that receives from
> a RS-232 port and I just can't seem to get it to do anything.
> 
>   The port I am reading is connected to a scanner radio and
> produces generally short lines of text such as CD13, - or +, each
> followed by a carriage return so these data should be very easy
> to read.
> 
>   If I use the kermit program, I do see the data when the
> radio receives a signal but if I run the following script which
> should hold and wait for some data, it holds and waits forever
> even when data are present
> 
> #!/usr/bin/perl -w
> use strict;
> use Device::SerialPort;
> 
> sub comm {#serialport
> 
> my $port = Device::SerialPort->new("/dev/ttyUSB0");
> $port->baudrate(9600); # Configure this to match your device
> $port->databits(8);
> $port->parity("none");
> $port->stopbits(1);
>$port->handshake("none");
>$port->write_settings;
> #This is supposed to flush the buffers.
> $port->lookclear;
> #This causes an infinite loop so it should hang and receive
> #characters.
> while (1) {
>my $char = $port->lookfor;
> #When there is nothing, go back and keep retrying.
> if ($char) {
>print "$char\n";
> }
>}
> return;
> }#serial port
> 
> #Call the subroutine.
> 
> comm;
> 
>   If this was working, it would show a column of all the
> ASCII characters being received.  /dev/ttyUSB0 is a valid device
> and works when used with kermit or even a C program I wrote.
> 
>   If anybody has gotten the perl Device::SerialPort to
> work, I am interested to know what I am doing or not doing.
> 
>   Thank you for any constructive ideas.
> 
> Martin McCormick  WB5AGZ
>

This is a good starting point:
http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/
It is not perl centric (c in fact). But it tells you the general basics for
serial communication.

-H 

-- 
Henning Follmann   | hfollm...@itcfollmann.com

estamated number of Linux users?

[Karen Lewellen]

Hi all,
Any place where this number exists?  I would include those companies and 
web professionals, using Linux servers as apart of their craft?

Thanks,
Karen


"No one is born hating another person because of the color of his
skin or his background or his religion ... People must learn to
hate, and if they can learn to hate, they can be taught to
love... For love comes more naturally to the human heart than its
opposite." Nelson Mandela.

Re: Serial Ports and Perl

[Andy Smith]

Hi Martin,

On Thu, Oct 26, 2017 at 07:37:07PM -0500, Martin McCormick wrote:
>   If anybody has gotten the perl Device::SerialPort to
> work, I am interested to know what I am doing or not doing.

I have been using it successfully for a long time, but all I do is
read whole lines from the serial device like:

my $dev  = '/dev/ttyUSB0';
my $port = Device::SerialPort->new($dev);

$port->baudrate(57600);
$port->write_settings;

open my $fh, '<', $dev or die "Can't open $dev: $!";

while (<$fh>) {
print "READ: $_\n";
}

So, I am only using Device::SerialPort to configure the device,
while all reading is done by treating it as a normal file.

I see you are using lookfor(), which I have never used before. From
a brief look at:


http://search.cpan.org/~cook/Device-SerialPort-1.002/SerialPort.pm#Methods_for_I/O_Processing

it seems you should be setting are_match() if you want lookfor() to
match anything.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: The new normal of logging

[Ben Caradoc-Davies]

On 27/10/17 13:02, Gene Heskett wrote:

On Thursday 26 October 2017 15:22:35 Nicholas Geovanis wrote:

" And there's also systemd, that is slowly phagocytosing the UNIX part
of Linux"

I'm old enough to have taken phonics in grade school, but that obviously
invented word could probably be replaced by a 4 letter adjective...


Invented, yes, but over 130 years ago. The term phagocyte was coined in 
about 1883 by Carl Friedrich Wilhelm Claus to describe the cells 
discovered by Ilya Mechnikov, winner of the 1908 Nobel Prize in Medicine:

https://en.wikipedia.org/wiki/Carl_Friedrich_Wilhelm_Claus
https://en.wikipedia.org/wiki/Élie_Metchnikoff
https://www.nobelprize.org/nobel_prizes/medicine/laureates/1908/
https://www.nobelprize.org/nobel_prizes/medicine/laureates/1908/mechnikov-bio.html
https://en.wikipedia.org/wiki/Phagocyte
https://en.wikipedia.org/wiki/Phagocytosis

And you would need a verb in the present tense, not an adjective, so 
probably more than four letters.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Serial Ports and Perl

[Martin McCormick]

The perl list I subscribe to seems to be on the fritz or I would
take the question there.  I want to write code that receives from
a RS-232 port and I just can't seem to get it to do anything.

The port I am reading is connected to a scanner radio and
produces generally short lines of text such as CD13, - or +, each
followed by a carriage return so these data should be very easy
to read.

If I use the kermit program, I do see the data when the
radio receives a signal but if I run the following script which
should hold and wait for some data, it holds and waits forever
even when data are present

#!/usr/bin/perl -w
use strict;
use Device::SerialPort;

sub comm {#serialport

my $port = Device::SerialPort->new("/dev/ttyUSB0");
$port->baudrate(9600); # Configure this to match your device
$port->databits(8);
$port->parity("none");
$port->stopbits(1);
   $port->handshake("none");
   $port->write_settings;
#This is supposed to flush the buffers.
$port->lookclear;
#This causes an infinite loop so it should hang and receive
#characters.
while (1) {
   my $char = $port->lookfor;
#When there is nothing, go back and keep retrying.
if ($char) {
   print "$char\n";
}
   }
return;
}#serial port

#Call the subroutine.

comm;

If this was working, it would show a column of all the
ASCII characters being received.  /dev/ttyUSB0 is a valid device
and works when used with kermit or even a C program I wrote.

If anybody has gotten the perl Device::SerialPort to
work, I am interested to know what I am doing or not doing.

Thank you for any constructive ideas.

Martin McCormick  WB5AGZ

Re: The new normal of logging

[Gene Heskett]

On Thursday 26 October 2017 15:22:35 Nicholas Geovanis wrote:

> On Thu, Oct 26, 2017 at 1:46 PM, Jonathan de Boyne Pollard <
>
> j.deboynepollard-newsgro...@ntlworld.com> wrote:
> > Roberto C. Sánchez:
> >
> > Is this the new normal, for things to get captured in some systemd
> > log
> >
> >> [...]?
> >>
> >> * https://unix.stackexchange.com/a/294206/5132 Yes.
>
> Thanks for that. And quoting that article
> " And there's also systemd, that is slowly phagocytosing the UNIX part
> of Linux"
>
> :-D

I'm old enough to have taken phonics in grade school, but that obviously 
invented word could probably be replaced by a 4 letter adjective...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Thursday 26 October 2017 12:13:57 Nicholas Geovanis wrote:

> An interesting, accidental FYI on the subject of the resolvconf
> package: Just now I upgraded an Ubuntu 17.04 test machine which was
> fully upgraded only ten days ago. I see in the pending upgrade details
> that resolvconf is "No longer supported by Canonical" since the
> previous upgrade.
>
Gee, I wonder why, said Gene to no one in particular ;-)

> On Thu, Oct 26, 2017 at 10:54 AM, The Wanderer  
wrote:
> > On 2017-10-26 at 11:35, Glenn English wrote:
> > > On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone 
> >
> > wrote:
> > >> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> > >>> and made immutable. Particularly is the fact that
> > >>> /etc/resolv.conf
> >
> > isn't
> >
> > >>> a link to something else but contains:
> > >>>
> > >>> nameserver 192.168.XX.1
> > >>> search  hostdns
> > >>> domain coyote.den
> > >>
> > >> Please stop posting that, it uses incorrect syntax
> > >
> > > The 'search host dns' line? How do you set that order? I couldn't
> > > find that from a bit of surfing, and I'd like to have name lookups
> > > work in that order...
> >
> > As was explained later on in this thread (and, I presume, would have
> > been explained to Gene previously in other threads), you set that
> > search order in /etc/nsswitch.conf, not in /etc/resolv.conf.
> >
> > 'man nsswitch.conf' documents the file, but all you should probably
> > need to do is look at the existing file, and tweak the 'hosts' line
> > appropriately.
> >
> >
> > If what you want is "search /etc/hosts, then search DNS, then give
> > up", the 'hosts' line you want is:
> >
> > hosts:  files dns
> >
> > There are additional options that might make sense, but that's the
> > most basic form.
> >
> >
> > My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
> > except maybe for a bit of reordering, reads:
> >
> > hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
> >
> > which, according to my understanding, simply adds a few additional
> > types of DNS lookup into the series before giving up.
> >
> > --
> >The Wanderer
> >
> > The reasonable man adapts himself to the world; the unreasonable one
> > persists in trying to adapt the world to himself. Therefore all
> > progress depends on the unreasonable man. -- George Bernard
> > Shaw


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Thursday 26 October 2017 11:35:06 Glenn English wrote:

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  
wrote:
> > On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> >> and made immutable. Particularly is the fact that /etc/resolv.conf
> >> isn't a link to something else but contains:
> >>
> >> nameserver 192.168.XX.1
> >> search  hostdns
> >> domain coyote.den
> >
> > Please stop posting that, it uses incorrect syntax
>
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...
>
That is under the keyword 'search' in the man page, where the confusion 
is about what to put there stems from the rest of that stanza. It obtuse 
and clueless except for a later statement the says search and domain are 
mutually exclusive, using the last option found.

As to what you put in the search line, I haven't a clue. I modified mine 
to:
nameserver 192.168.XX.1
search  coyote.den  nameserver

And ANAICT it made zero difference as it still Just Works(TM).

Someone else has pointed out that this is actually controlled
by nsswitch.conf, which contains:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, 
try:

# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group:  compat
shadow: compat

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

And while I'd not call that man page language swahili, it may be slightly 
better than the  man page for resolv.conf. The operative line above may 
be the "hosts:" line.  I'll leave the study of that man page for those 
search for a solution to a problem they are having. I'll note that the 
debian wheezy supplied file is quite heavily modified when compared to 
the example file in that man page. But no clue as to what problems the 
modifications are intended to fix. There may be more info in the 
ChangeLog.gz for these two files.

I know roughly where those are, but have been up to my eyeballs in a 60 
yo 1kw Gates am radio transmitter the last 2 days, and out of this loop.
The real secret here is that I am of a dying breed in the broadcast 
world, I am one of the folks who actually go on call to fix things like 
transmitters.  Most field engineers just pick up the phone and order a  
new one, for anything from 10G's for a 50 watt nighttime transmitter, to 
a couple million $ for a modern digital tv transmitter.

This one has quite extensive damage to the audio driver pcb brought on by 
it being on a phenolic substrate, and the OEM solder was the same stuff 
RCA used in their TV's circa 1953-54. Darned near pure lead with a need 
to be heated and diluted with more modern, 250F lower melting temp 
solder before it can be removed to gain access to the component lead, 
1/4" of which was bent over, locking it firmly to the board even if the 
solder was melted.

The end result of course is copper traces lifted from the board by the 
excessive heat and loaded with microscopic cracks. I replaced several 
old carbon composition resistors that were way out of tolerance, but the 
final "fix" was a piece of 22 gauge wire connecting the two ends of a 
trace carrying 500 volt on the theory that if the trace was broken 
someplace in the middle, it was now being fed on both sides of the 
break.  And it worked.  That faint thumping you can hear in the 
background, is me pecking on wood for good luck.

A new circuit board has been checked on, it would have to be made, min 
order 3 for around $11,000. So we cobble this one up yet one more time.

But I'm likely both writing swahili to most of you, and boring the whole 
list.  So I'll STFU.

> And Gene,
>
> Removing all write permissions and setting immutable has stopped
> Comcast from trashing my resolv.conf. This week.

Probably for a good long time I suspect.

> Have you looked to see whether the changes are being done by an alien
> (Comcast) or from inside the host?
>
> --
> Glenn English


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

a

[Sanaa Austin]

Sent from my iPhone

Re: bash usage.

[Jude DaShiell]

bash has a comments syntax to document what may not necessarily be clear 
with scripts.  If I write a script at minimum just below the 
#!/usr/bin/env bash line I have a # file: line giving the file name 
followed by a dash and a little bit of a description what the script is 
supposed to do.  Each to their own though, I just find that for me when 
I don't remember what a file does by its file name, I can search the two 
top lines using head -2 filename.sh and suddenly remember what I was 
trying to do with that script.


On Thu, 26 Oct 2017, David Margerison wrote:


Date: Thu, 26 Oct 2017 08:12:16
From: David Margerison 
To: "debian-user@lists.debian.org" 
Subject: Re: bash usage.
Resent-Date: Thu, 26 Oct 2017 12:30:18 + (UTC)
Resent-From: debian-user@lists.debian.org

On 26 October 2017 at 21:59, Roberto C. S?nchez  wrote:

On Thu, Oct 26, 2017 at 04:19:42PM +1100, David Margerison wrote:

On 26 October 2017 at 12:23, Roberto C. S?nchez  wrote:


mountpoint -q $WorkingDirectory
if [[ $? = 0 ]]


That will work, but is ridiculous considering this works by design:

if mountpoint -q "$wd" ; then
  echo "$wd is a mountpoint"
fi


Yes, quite right.  Though, my syntax makes it clear that what is being
tested/evlauated is the exit status, not the output.  I know that the if
evaluates the exit status, but that may not be immediately evident to
someone who is not particularly familiar with shell programming.


That's a fair point, but the documentation of the 'if' statement in 'man bash'
will make that immediately clear to anyone who cares to read it.

The [[ test, the $? parameter, and the =0 test are three separate
redundancies that are not needed here to achieve the desired result.

So the code you gave is a good illustration of how $? works, but should
also be identified as a bad example of how to correctly achieve the goal
in this case.

Because in shell syntax, the 'if' statement is conceived and intended
to be used directly with any/all commands.

So I believe that good guidance should make that point clearly, and that
is my reason for writing again here, to present that alternative.

Also, some shells do not support [[ and its syntax differs from [ and 'test'
in various fun ways.




--

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 12:31:32PM -0700, Don Armstrong wrote:
> On Thu, 26 Oct 2017, Roberto C. Sánchez wrote:
> > I do have a syslog package installed and running. It is possible I
> > misremembered what was previously logged where, but there is a clear
> > discrepancy between what goes to syslog and what systemd captures:
> 
> [...]
> 
> > In particular, systemd appears to capture this line:
> > 
> > ifup[35433]: mv: cannot move '/etc/resolv.conf.dhclient-new.35546' to
> > '/etc/resolve.conf'
> 
> That's because systemd also captures STDERR, even if that isn't directly
> logged using syslog(). It's one of the rather nice features of systemd.
> 
I've tripped over the different approach systemd takes so many times it
is nice to finally encounter something it does better.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Don Armstrong]

On Thu, 26 Oct 2017, Roberto C. Sánchez wrote:
> I do have a syslog package installed and running. It is possible I
> misremembered what was previously logged where, but there is a clear
> discrepancy between what goes to syslog and what systemd captures:

[...]

> In particular, systemd appears to capture this line:
> 
> ifup[35433]: mv: cannot move '/etc/resolv.conf.dhclient-new.35546' to
> '/etc/resolve.conf'

That's because systemd also captures STDERR, even if that isn't directly
logged using syslog(). It's one of the rather nice features of systemd.

-- 
Don Armstrong  https://www.donarmstrong.com

This isn't life in the fast lane, it's life in the oncoming traffic
 -- Terry Pratchett

Re: The new normal of logging

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 07:46:12PM +0100, Jonathan de Boyne Pollard wrote:
> Roberto C. Sánchez:
> 
> > Is this the new normal, for things to get captured in some systemd log
> > [...]?
> > 
> * https://unix.stackexchange.com/a/294206/5132 Yes.
> 

That is very informative.  In particular:

| If it can connect (as a client) to an AF_LOCAL datagram socket at
| /run/systemd/journal/syslog it writes journal data there, if forwarding
| to syslog is configured.

I need to make sure that I have that forwarding propery configured on my
systems.

Then also: 

| systemd itself arranges for the standard outputs and errors of (some)
| services to be attached to the /run/systemd/journal/stdout socket. So
| dæmons that log to standard error in the normal fashion have their
| output sent to the journal.

That does seem quite useful and from what I have experienced the last
few days nicely handles the case where something that should log to
syslog calls a command and then ignores its stdout/stderr.  The systemd
journal was seeing that stderr text where syslog was not.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: The new normal of logging

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 1:46 PM, Jonathan de Boyne Pollard <
j.deboynepollard-newsgro...@ntlworld.com> wrote:

> Roberto C. Sánchez:
>
> Is this the new normal, for things to get captured in some systemd log
>> [...]?
>>
>> * https://unix.stackexchange.com/a/294206/5132 Yes.
>

Thanks for that. And quoting that article
" And there's also systemd, that is slowly phagocytosing the UNIX part of
Linux"

:-D

The new normal of logging

[Jonathan de Boyne Pollard]

Roberto C. Sánchez:

Is this the new normal, for things to get captured in some systemd log 
[...]?



* https://unix.stackexchange.com/a/294206/5132 Yes.

PXE netboot to load OS from /dev/sda1

[John Naggets]

Hi,

I have installed Debian 9 onto an old laptop with an SSD disk.
Unfortunately the BIOS does not support booting from that SSD disk so
I would like to "abuse" of PXE in order to boot my installed Linux
from /dev/sda1.

For that purpose I setup a PXE server on another machine on the same
LAN using the netboot.tar.gz file from Debian 9 and slightly adapted
the pxelinux.cfg/default file to add the following entry:

LABEL netboot
KERNEL debian-installer/amd64/linux
APPEND initrd=debian-installer/amd64/initrd.gz root=/dev/sda1

Unfortunately it still boots the Debian installer and somehow does not
boot from /dev/sda1. I thought having "root=/dev/sda1" should make it
boot from /dev/sda1 and hence skip the installer part. At least I
think it used to work in the past.

Does anyone see what I am missing here?

Best,
John

Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 11:13 AM, Nicholas Geovanis 
wrote:

> An interesting, accidental FYI on the subject of the resolvconf package:
> Just now I upgraded an Ubuntu 17.04 test machine which was fully upgraded
> only ten days ago. I see in the pending upgrade details that resolvconf is
> "No longer supported by Canonical" since the previous upgrade.
>

I should have mentioned that this is the upgrade to Ubuntu 17.10 incoming.

Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

An interesting, accidental FYI on the subject of the resolvconf package:
Just now I upgraded an Ubuntu 17.04 test machine which was fully upgraded
only ten days ago. I see in the pending upgrade details that resolvconf is
"No longer supported by Canonical" since the previous upgrade.


On Thu, Oct 26, 2017 at 10:54 AM, The Wanderer  wrote:

> On 2017-10-26 at 11:35, Glenn English wrote:
>
> > On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone 
> wrote:
> >
> >> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> >>>
> >>> and made immutable. Particularly is the fact that /etc/resolv.conf
> isn't
> >>> a link to something else but contains:
> >>>
> >>> nameserver 192.168.XX.1
> >>> search  hostdns
> >>> domain coyote.den
> >>
> >> Please stop posting that, it uses incorrect syntax
> >
> > The 'search host dns' line? How do you set that order? I couldn't find
> > that from a bit of surfing, and I'd like to have name lookups work in
> > that order...
>
> As was explained later on in this thread (and, I presume, would have
> been explained to Gene previously in other threads), you set that search
> order in /etc/nsswitch.conf, not in /etc/resolv.conf.
>
> 'man nsswitch.conf' documents the file, but all you should probably need
> to do is look at the existing file, and tweak the 'hosts' line
> appropriately.
>
>
> If what you want is "search /etc/hosts, then search DNS, then give up",
> the 'hosts' line you want is:
>
> hosts:  files dns
>
> There are additional options that might make sense, but that's the most
> basic form.
>
>
> My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
> except maybe for a bit of reordering, reads:
>
> hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
>
> which, according to my understanding, simply adds a few additional types
> of DNS lookup into the series before giving up.
>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>

Re: Why does resolv.conf keep changing?

[The Wanderer]

On 2017-10-26 at 11:35, Glenn English wrote:

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  wrote:
>
>> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
>>>
>>> and made immutable. Particularly is the fact that /etc/resolv.conf isn't
>>> a link to something else but contains:
>>>
>>> nameserver 192.168.XX.1
>>> search  hostdns
>>> domain coyote.den
>>
>> Please stop posting that, it uses incorrect syntax
> 
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...

As was explained later on in this thread (and, I presume, would have
been explained to Gene previously in other threads), you set that search
order in /etc/nsswitch.conf, not in /etc/resolv.conf.

'man nsswitch.conf' documents the file, but all you should probably need
to do is look at the existing file, and tweak the 'hosts' line
appropriately.


If what you want is "search /etc/hosts, then search DNS, then give up",
the 'hosts' line you want is:

hosts:  files dns

There are additional options that might make sense, but that's the most
basic form.


My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
except maybe for a bit of reordering, reads:

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

which, according to my understanding, simply adds a few additional types
of DNS lookup into the series before giving up.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Thu, Oct 26, 2017 at 03:35:06PM +, Glenn English wrote:
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...

Gene's resolv.conf has this erroneous line that he has been maintaining
for decades.  It does not do what he thinks it does.

If you want to control the order of name lookup sources, that goes in
the /etc/nsswitch.conf file, as described in "man nsswitch.conf".

Re: Why does resolv.conf keep changing?

[Glenn English]

On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  wrote:
> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
>>
>> and made immutable. Particularly is the fact that /etc/resolv.conf isn't
>> a link to something else but contains:
>>
>> nameserver 192.168.XX.1
>> search  hostdns
>> domain coyote.den
>
>
> Please stop posting that, it uses incorrect syntax

The 'search host dns' line? How do you set that order? I couldn't find
that from a bit of surfing, and I'd like to have name lookups work in
that order...

And Gene,

Removing all write permissions and setting immutable has stopped
Comcast from trashing my resolv.conf. This week.

Have you looked to see whether the changes are being done by an alien
(Comcast) or from inside the host?

--
Glenn English

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 09:31:47AM -0500, David Wright wrote:
> 
> Judging by your address and earlier comment, you're much closer to
> Debian's strategy than I am, but I thought the thrust of Debian was
> to coerce/persuade packages to cooperate on /etc/resolv.conf so that
> one package did not overwrite the actions of another on starting,
> and could unroll their own changes when terminating. It's always
> worked here with ifup and dhclient, but that's less complex than
> your own situation using bind. (I use /etc/hosts for my own LAN.)
> 
You make a good point.  However, I think that requiring the user/admin
to implement a hook script in order to reliably get dhclient to do the
right thing is a bit much.  That is why I made the suggestion about the
configuration directive.

> 
> An official hack (Debian) rather than an unofficial one (sys admin)?
> The most remarkable thing in this thread is the alleged defeat of
> chattr +i. (a) it's difficult to believe that some package comes
> along and unsets i (immutable attribute), changes the file, and sets
> i again, which is what you allege. (b) although I agreed with Gene
> that a watch could be left untriggered by i being set, this would
> only happen if a package tried to naively change resolv.conf; the
> behaviour alleged in (a) would still trigger the watch at the time
> i was temporarily unset. (c) the third alternative is failure of
> i to do its job, which seems unlikely.
> 
I had several terminal windows open and I am beginning to suspect that I
was mistaken (at least initially) about having set +i.  In particular,
when I later tried again (possibly for the first time it now seems) I
observed that new temporary files were littered in /etc after the
dhclient-script attempt to overwrite the original /etc/resolv.conf
failed.  I am going to just call it user error on my part.

> So perhaps Debian should just adopt chattr +i as the official way
> of doing what Gene, Greg and you want, with a warning that you
> might want to clean up any clutter (resolv.conf.foo…) periodically.
> Anything that interfered with that could then be filed as a bug.
> 
I do not find this a particularly good solution because it would likely
interfere with managing a system via puppet, ansible, etc.  There is
definitely a use case for "this file should be changeable only by the
administrator, not by any automated functionality from an installed
package."

> BTW did you find out why you were getting DHCP negotiations
> every 3 or 4 minutes? The lease you posted was for 16005 seconds,
> over 4 hours.
> 
I don't recall this being a problem except for when I manually ran
dhclient to force a new negotiation.  I have not observed anything that
makes me think there is an issue with premature renegotiation.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[David Wright]

On Thu 26 Oct 2017 at 07:46:24 (-0400), Roberto C. Sánchez wrote:
> On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> > 
> > Actually, there's no need to duplicate the effort. As I understand it,
> > resolvconf is basically an optional helper program. Software that
> > automatically modifies /etc/resolv.conf should first test for the presence
> > of resolvconf (whether that be checking for the configuration directory of
> > resolvconf or checking that resolvconf is running or... however resolvconf
> > desires to be detected). If resolvconf is available, the changes are
> > co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
> > directly.
> > 
> In my case resolvconf is not installed/available and I want resolv.conf
> to be left alone.  I want any other package that thinks it needs to
> modify resolv.conf to leave it along.  I also think that would be useful
> in the case where resolvconf gets unexpected installed later.  That is
> not a specific concern for me, but in a situation where multiple
> administrators are involved with managing a system it could happen.
> 
> Based on your proposal the situation which I have would not be
> addressed.  I am specifically saying that there should be a way to mark
> resolv.conf as static so that any package that touches it can check for
> that directive.  There is no need for packages to coordinate between
> themselves in that case.  They need only to check for the marker in
> resolv.conf and if it is there (indicating that it should not be
> modified) then they simply discontinue processing.

Judging by your address and earlier comment, you're much closer to
Debian's strategy than I am, but I thought the thrust of Debian was
to coerce/persuade packages to cooperate on /etc/resolv.conf so that
one package did not overwrite the actions of another on starting,
and could unroll their own changes when terminating. It's always
worked here with ifup and dhclient, but that's less complex than
your own situation using bind. (I use /etc/hosts for my own LAN.)

> > The problem is that I don't think that resolvconf can require packages to
> > use it. This is similar to other higher-level APIs such as pulseaudio. If
> > the software knows to use pulseaudio, then it can get mixed, rerouted etc by
> > pulseaudio, but it's difficult to mandate that software stop sending audio
> > directly to /dev/dsp (well, unless you're a distribution which applies
> > patches to upstream software in order to harmonize the experience of its
> > users).
> > 
> 
> I can see the utility of resolvconf and in packages coordinating their
> modifications of resolv.conf.  However, I still maintain that there
> should be a simple way for the admin to mark resolv.conf in such a way
> that no package will modify it.  This should be possible without
> resorting to hacks like making resolv.conf immutable.

An official hack (Debian) rather than an unofficial one (sys admin)?
The most remarkable thing in this thread is the alleged defeat of
chattr +i. (a) it's difficult to believe that some package comes
along and unsets i (immutable attribute), changes the file, and sets
i again, which is what you allege. (b) although I agreed with Gene
that a watch could be left untriggered by i being set, this would
only happen if a package tried to naively change resolv.conf; the
behaviour alleged in (a) would still trigger the watch at the time
i was temporarily unset. (c) the third alternative is failure of
i to do its job, which seems unlikely.

So perhaps Debian should just adopt chattr +i as the official way
of doing what Gene, Greg and you want, with a warning that you
might want to clean up any clutter (resolv.conf.foo…) periodically.
Anything that interfered with that could then be filed as a bug.

BTW did you find out why you were getting DHCP negotiations
every 3 or 4 minutes? The lease you posted was for 16005 seconds,
over 4 hours.

Cheers,
David.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 8:06 AM, Roberto C. Sánchez 
wrote:

>
> Is this the new normal, for things to get captured in some systemd log
> that I cannot grep out of /var/log?


Unfortunately yes.
My experience with Debian 8/9 and more recent Ubuntu is that there is now no
escaping it. One could use instead the SysV init package in Debian, it
seems to be
fully usable in 9, but my management tells me that is not an option.

Roberto C. Sánchez
>
>

Re: debian zfs spl dkms build fails

[Russell L. Carter]

On 10/25/17 22:19, David Christensen wrote:

On 10/25/17 21:23, Russell L. Carter wrote:

Greetings.  Your reply is completely nonresponsive to
the zfs kernel upgrade situation as it is today on debian.

Why did you bother?  It's weird.

I don't actually care very much.  I'm going to go back to
dumb extfs if required.  I'm just fishing for some sanity
here.


Please don't top post.


I bothered because the last time I tried ZOL (Debian 6?), the only 
option was to download the source from LLNL and build it.  Now there are 
official Debian binary packages available.  Thank you for providing the 
stimulus for me to discover that fact.  :-)



It appears that you are attempting to build the "testing" version of ZFS:

     https://packages.debian.org/buster/zfs-dkms


Yet, you expect the reliability of "stable".  Make sure you understand 
the three releases of Debian:


     https://www.debian.org/releases/


If you want stability, run "stable".  If you have the skills and 
interest to help fix bugs, then run "testing" or "unstable".




I've been running debian 'testing' for 18 years now.  I've been running
zfs on other OS's for 5 years now, some quite large.   Those other OSs
include some I've been running for over 20 years.  It should be inferred
that I've watched a lot of technology get integrated over that time.

Note that my complaint here is that the upgrade process that I've done
literally 1000s of times over that 18 years is now allowed to not only
break the *upgrade* process through broken kernel modules, it has the
added benefit of breaking *existing* working configurations.  That's
quite a packaging accomplishment, for 2017.

I take your commentary as confirmation on what I suspected.  Ideology
somehow has broken the technology integration process.  Oh well.

Out.  And out of using debian for a real OS.  But for 'testing' hey,
it's just great.  I've got my full backup and now I'm going to make
this a stupid box.

Russell




David

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 09:35:03AM -0400, Greg Wooledge wrote:
> On Thu, Oct 26, 2017 at 09:06:09AM -0400, Roberto C. Sánchez wrote:
> > debian:/etc# systemctl status networking
> > [...]
> > Is this the new normal, for things to get captured in some systemd log
> > that I cannot grep out of /var/log?  I specifically recall in the past
> > on older pre-systemd systems that these exchanges between the DHCP
> > client and server would get logged by syslog.
> > 
> > I guess this explains why things that I recalled being logged in the
> > past suddenly disappeared from syslog.
> 
> I seem to have the information in both places.
> 
> wooledg:~$ grep dhclient /var/log/syslog
> Oct 26 08:39:56 wooledg dhclient[514]: DHCPREQUEST of 10.76.172.97 on eth0 to 
> 10.127.1.4 port 67
> Oct 26 08:39:56 wooledg dhclient[514]: DHCPACK of 10.76.172.97 from 10.127.1.4
> Oct 26 08:39:56 wooledg dhclient[514]: bound to 10.76.172.97 -- renewal in 
> 119104 seconds.
> 
> Are you sure you've got rsyslog installed and running?
> 
I do have a syslog package installed and running.  It is possible I
misremembered what was previously logged where, but there is a clear
discrepancy between what goes to syslog and what systemd captures:

debian:/etc# date
Thu Oct 26 09:39:02 EDT 2017
debian:/etc# chattr +i /etc/resolv.conf
debian:/etc# systemctl restart networking
debian:/etc# egrep 'Oct 26 09:39.*dhclient' /var/log/syslog
Oct 26 09:39:10 debian dhclient[35357]: Killed old client process
Oct 26 09:39:11 debian dhclient[35357]: Internet Systems Consortium DHCP Client 
4.3.5
Oct 26 09:39:11 debian dhclient[35357]: Copyright 2004-2016 Internet Systems 
Consortium.
Oct 26 09:39:11 debian dhclient[35357]: All rights reserved.
Oct 26 09:39:11 debian dhclient[35357]: For info, please visit 
https://www.isc.org/software/dhcp/
Oct 26 09:39:11 debian dhclient[35357]:
Oct 26 09:39:11 debian dhclient[35357]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:11 debian dhclient[35357]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:11 debian dhclient[35357]: Sending on   Socket/fallback
Oct 26 09:39:11 debian dhclient[35357]: DHCPRELEASE on eth1 to 192.168.63.1 
port 67
Oct 26 09:39:12 debian dhclient[35528]: Internet Systems Consortium DHCP Client 
4.3.5
Oct 26 09:39:12 debian dhclient[35528]: Copyright 2004-2016 Internet Systems 
Consortium.
Oct 26 09:39:12 debian dhclient[35528]: All rights reserved.
Oct 26 09:39:12 debian dhclient[35528]: For info, please visit 
https://www.isc.org/software/dhcp/
Oct 26 09:39:12 debian dhclient[35528]:
Oct 26 09:39:12 debian dhclient[35528]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian dhclient[35528]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian dhclient[35528]: Sending on   Socket/fallback
Oct 26 09:39:12 debian dhclient[35528]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 7
Oct 26 09:39:19 debian dhclient[35528]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 13
Oct 26 09:39:19 debian dhclient[35528]: DHCPREQUEST of 192.168.63.197 on eth1 
to 255.255.255.255 port 67
Oct 26 09:39:19 debian dhclient[35528]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian dhclient[35528]: DHCPACK of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian dhclient[35528]: bound to 192.168.63.197 -- renewal in 
14309 seconds.
debian:/etc# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
   Active: active (exited) since Thu 2017-10-26 09:39:19 EDT; 56s ago
 Docs: man:interfaces(5)
  Process: 35274 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo 
(code=exited, status=0/SUCCESS)
  Process: 35433 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=0/SUCCESS)
  Process: 35427 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-en
 Main PID: 35433 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 9830)
   CGroup: /system.slice/networking.service
   └─35558 /sbin/dhclient -4 -v -pf /run/dhclient.eth1.pid -lf 
/var/lib/dhcp/dhclient.eth1.leases

Oct 26 09:39:12 debian ifup[35433]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian ifup[35433]: Sending on   Socket/fallback
Oct 26 09:39:12 debian ifup[35433]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 7
Oct 26 09:39:19 debian ifup[35433]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 13
Oct 26 09:39:19 debian ifup[35433]: DHCPREQUEST of 192.168.63.197 on eth1 to 
255.255.255.255 port 67
Oct 26 09:39:19 debian ifup[35433]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian ifup[35433]: DHCPACK of 192.168.63.197 from 192.168.63.1
Oct 26 09:39:19 debian ifup[35433]: mv: cannot move 
'/etc/resolv.conf.dhclient-new.35546' to '/etc/reso
Oct 26 09:39:19 debian ifup[35433]: bound to 192.168.63.197 -- renewal in 14309 
seconds.
Oct 26 09:39:19 debian systemd[1]: Star

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Thu, Oct 26, 2017 at 09:06:09AM -0400, Roberto C. Sánchez wrote:
> debian:/etc# systemctl status networking
> [...]
> Is this the new normal, for things to get captured in some systemd log
> that I cannot grep out of /var/log?  I specifically recall in the past
> on older pre-systemd systems that these exchanges between the DHCP
> client and server would get logged by syslog.
> 
> I guess this explains why things that I recalled being logged in the
> past suddenly disappeared from syslog.

I seem to have the information in both places.

wooledg:~$ grep dhclient /var/log/syslog
Oct 26 08:39:56 wooledg dhclient[514]: DHCPREQUEST of 10.76.172.97 on eth0 to 
10.127.1.4 port 67
Oct 26 08:39:56 wooledg dhclient[514]: DHCPACK of 10.76.172.97 from 10.127.1.4
Oct 26 08:39:56 wooledg dhclient[514]: bound to 10.76.172.97 -- renewal in 
119104 seconds.

Are you sure you've got rsyslog installed and running?

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:
> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
> What it does to it is to replace it with a symlink.
> After that, it doesn't touch it any morel instead it only modifies the file
> that is the target of that symlink.
> 
> So there's your answer:
> - rm /etc/resolv.conf
> - zile /etc/resolv.conf

How is this supposed to prevent dhclient (et al.) from modifying the
file, then?

A quick read of /sbin/dhclient-script shows me nothing promising.
(It's also full of bugs, which is exactly what one expects in a
shell script provided by an OS package, or to be fair, any shell
script at all.)

A quick read of

is... interesting, but low on details.  It doesn't tell me what
resolvconf actually DOES, how it prevents other things from writing
to the file.  But see below.

Hmm... how COULD it work?

Checking  
Aha!  Installing resolvconf creates a file named
/etc/dhcp/dhclient-enter-hooks.d/resolvconf in the dhclient
hooks directory.  Maybe this file overrides the make_resolv_conf
shell function that dhclient-script provides.  I would have to
download and extract the resolvconf package to find out, since I
don't have it installed anywhere.

But what's most interesting to me is this paragraph in the resolvconf
man page:

  In some situations resolvconf needs to act as a deterrent to writing
  to /etc/resolv.conf. Where this file cannot be made immutable or you
  just need to toggle this behaviour, resolvconf can be disabled by
  adding resolvconf=NO to resolvconf.conf(5).

Sounds like chattr +i IS actually the preferred solution.  Installing and
configuring resolvconf is the fallback solution.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:
> 
> As an additional note, it is strange to me that none of the dhclient
> interactions are logged in syslog.  When I ran dhclient directly and
> specified the verbose option, that resulted in the exhanges being logged
> to syslog, except for the error message.  It appears that the scripts
> are not properly capturing/redirecting the standard error stream.  I
> will also investigate if a bug has been filed for that.  If one has not
> been filed I will do that as well.
> 

I sort of stumbled upon something peculiar related to this.

debian:/etc# systemctl restart networking
debian:/etc# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
   Active: active (exited) since Thu 2017-10-26 08:51:35 EDT; 5s ago
 Docs: man:interfaces(5)
  Process: 30299 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo 
(code=exited, status=0/SUCCESS)
  Process: 30455 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=0/SUCCESS)
  Process: 30451 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-en
 Main PID: 30455 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 9830)
   CGroup: /system.slice/networking.service
   └─30573 /sbin/dhclient -4 -v -pf /run/dhclient.eth1.pid -lf 
/var/lib/dhcp/dhclient.eth1.leases

Oct 26 08:51:31 debian ifup[30455]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 08:51:31 debian ifup[30455]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 08:51:31 debian ifup[30455]: Sending on   Socket/fallback
Oct 26 08:51:31 debian ifup[30455]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 3
Oct 26 08:51:35 debian ifup[30455]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 5
Oct 26 08:51:35 debian ifup[30455]: DHCPREQUEST of 192.168.63.197 on eth1 to 
255.255.255.255 port 67
Oct 26 08:51:35 debian ifup[30455]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 08:51:35 debian ifup[30455]: DHCPACK of 192.168.63.197 from 192.168.63.1
Oct 26 08:51:35 debian ifup[30455]: bound to 192.168.63.197 -- renewal in 16926 
seconds.
Oct 26 08:51:35 debian systemd[1]: Started Raise network interfaces.

Is this the new normal, for things to get captured in some systemd log
that I cannot grep out of /var/log?  I specifically recall in the past
on older pre-systemd systems that these exchanges between the DHCP
client and server would get logged by syslog.

I guess this explains why things that I recalled being logged in the
past suddenly disappeared from syslog.

> Why dhclient-script(8) mentions the hook scripts for overriding the
> behavior of make_resolv_conf() but not the configuration directives that
> can be used to affect specific values is also somewhat puzzling.
> 
Based on comments by Greg and Mike, it seems like the configuration
options are not quite as useful and concrete as I thought, so perhaps it
is better to direct users to the hook script.

-- 
Roberto C. Sánchez

Re: bash usage.

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 11:12:16PM +1100, David Margerison wrote:
> 
> That's a fair point, but the documentation of the 'if' statement in 'man bash'
> will make that immediately clear to anyone who cares to read it.
> 
You must regularly deal with different sorts of people than I do :-)

> The [[ test, the $? parameter, and the =0 test are three separate
> redundancies that are not needed here to achieve the desired result.
> 
> So the code you gave is a good illustration of how $? works, but should
> also be identified as a bad example of how to correctly achieve the goal
> in this case.
> 
That all depends on the definition of "correct" for a given situation.
If I were writing example code for my students that meant to illustrate
something I would likely choose something different than if I were
writing for a production environment with a team consisting of
experienced developers.

> Because in shell syntax, the 'if' statement is conceived and intended
> to be used directly with any/all commands.
> 
> So I believe that good guidance should make that point clearly, and that
> is my reason for writing again here, to present that alternative.
> 
> Also, some shells do not support [[ and its syntax differs from [ and 'test'
> in various fun ways.
> 
This is a good point, but the given example started with "#!/bin/bash"
indicating that the author likely intended to use bash-specific
constructs.

Personally, when I write specifically for bash (as opposed to more
generally for sh) I favor [[ over [ and test.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

>> > If Debian developers who are responsible for resolvconf are reading this,
>> > and if they actually CARE about making things work correctly and sensibly,
>> > then here is yet another proposal: give us a way to QUICKLY and EASILY
>> > and RELIABLY tell resolvconf "never do anything".
>> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
>> What it does to it is to replace it with a symlink.
>> After that, it doesn't touch it any morel instead it only modifies the file
>> that is the target of that symlink.
> Given that multiple packages potentially touch/change resolv.conf (at
> least resolvconf and the various DHCP clients),

That is not true: when resolvconf is installed, *no package* should
(modulo bugs) ever change /etc/resolv.conf.

Instead all changes go through resolvconf, which only modifies
/run/resolvconf/resolv.conf (and those changes usually get reflected
into /etc/resolv.conf by making it a symlink to that file, but that's
not mandatory).


Stefan "who thinks resolvconf should always be installed"

Re: bash usage.

[David Margerison]

On 26 October 2017 at 21:59, Roberto C. Sánchez  wrote:
> On Thu, Oct 26, 2017 at 04:19:42PM +1100, David Margerison wrote:
>> On 26 October 2017 at 12:23, Roberto C. Sánchez  wrote:
>> >
>> > mountpoint -q $WorkingDirectory
>> > if [[ $? = 0 ]]
>>
>> That will work, but is ridiculous considering this works by design:
>>
>> if mountpoint -q "$wd" ; then
>>   echo "$wd is a mountpoint"
>> fi
>
> Yes, quite right.  Though, my syntax makes it clear that what is being
> tested/evlauated is the exit status, not the output.  I know that the if
> evaluates the exit status, but that may not be immediately evident to
> someone who is not particularly familiar with shell programming.

That's a fair point, but the documentation of the 'if' statement in 'man bash'
will make that immediately clear to anyone who cares to read it.

The [[ test, the $? parameter, and the =0 test are three separate
redundancies that are not needed here to achieve the desired result.

So the code you gave is a good illustration of how $? works, but should
also be identified as a bad example of how to correctly achieve the goal
in this case.

Because in shell syntax, the 'if' statement is conceived and intended
to be used directly with any/all commands.

So I believe that good guidance should make that point clearly, and that
is my reason for writing again here, to present that alternative.

Also, some shells do not support [[ and its syntax differs from [ and 'test'
in various fun ways.

Re: Bug: updating Debian9 not "allowed".

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 11:50:05AM +, Joerg Desch wrote:
> I'm still running Debian 8 on all of my systems. Since it is time to 
> switch to Debian 9, I've tried to have a first look at it. So I've 
> installed the nonfree DVD-Image 9.2 within a VirtualBox container. All 
> went fine, until I've tried to update the APT database.
> 
> Both, apt and Synaptics updates fails. In both cases the error reports, 
> that /etc/apt/trusted.gpg is not accessible by user "_apt". 
> 
> The recommendation I've found was to delete trusted.gpg.
> 
> OK, this was a workaround for using apt. Both update and upgrade works 
> without errors. Trying Synaptics leads to the previous behavior. The file 
> trusted.gpg appears again and with this file, the error returns.
> 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#apt-unpriv-acquire
> 
> By the way... Why is the VirtualBox Guest Utils package not available in 
> the official repositories?
> 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466

However, there is now a backport:

https://packages.debian.org/source/stretch-backports/virtualbox

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Bug: updating Debian9 not "allowed".

[Darac Marjal]

On Thu, Oct 26, 2017 at 11:50:05AM +, Joerg Desch wrote:

I'm still running Debian 8 on all of my systems. Since it is time to
switch to Debian 9, I've tried to have a first look at it. So I've
installed the nonfree DVD-Image 9.2 within a VirtualBox container. All
went fine, until I've tried to update the APT database.

Both, apt and Synaptics updates fails. In both cases the error reports,
that /etc/apt/trusted.gpg is not accessible by user "_apt".

The recommendation I've found was to delete trusted.gpg.

OK, this was a workaround for using apt. Both update and upgrade works
without errors. Trying Synaptics leads to the previous behavior. The file
trusted.gpg appears again and with this file, the error returns.


[Aside: The debian packaging tool is called "synaptic". "Synaptics" are 
a company producing touchpads. The two are not related]


I believe this is a known bug in synaptic: #864640 [1].


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864640




By the way... Why is the VirtualBox Guest Utils package not available in
the official repositories?


It is: 
https://packages.debian.org/search?keywords=virtualbox-guest-utils







--
For more information, please reread.


signature.asc
Description: PGP signature

Bug: updating Debian9 not "allowed".

[Joerg Desch]

I'm still running Debian 8 on all of my systems. Since it is time to 
switch to Debian 9, I've tried to have a first look at it. So I've 
installed the nonfree DVD-Image 9.2 within a VirtualBox container. All 
went fine, until I've tried to update the APT database.

Both, apt and Synaptics updates fails. In both cases the error reports, 
that /etc/apt/trusted.gpg is not accessible by user "_apt". 

The recommendation I've found was to delete trusted.gpg.

OK, this was a workaround for using apt. Both update and upgrade works 
without errors. Trying Synaptics leads to the previous behavior. The file 
trusted.gpg appears again and with this file, the error returns.


By the way... Why is the VirtualBox Guest Utils package not available in 
the official repositories?

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> 
> Actually, there's no need to duplicate the effort. As I understand it,
> resolvconf is basically an optional helper program. Software that
> automatically modifies /etc/resolv.conf should first test for the presence
> of resolvconf (whether that be checking for the configuration directory of
> resolvconf or checking that resolvconf is running or... however resolvconf
> desires to be detected). If resolvconf is available, the changes are
> co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
> directly.
> 
In my case resolvconf is not installed/available and I want resolv.conf
to be left alone.  I want any other package that thinks it needs to
modify resolv.conf to leave it along.  I also think that would be useful
in the case where resolvconf gets unexpected installed later.  That is
not a specific concern for me, but in a situation where multiple
administrators are involved with managing a system it could happen.

Based on your proposal the situation which I have would not be
addressed.  I am specifically saying that there should be a way to mark
resolv.conf as static so that any package that touches it can check for
that directive.  There is no need for packages to coordinate between
themselves in that case.  They need only to check for the marker in
resolv.conf and if it is there (indicating that it should not be
modified) then they simply discontinue processing.

> The problem is that I don't think that resolvconf can require packages to
> use it. This is similar to other higher-level APIs such as pulseaudio. If
> the software knows to use pulseaudio, then it can get mixed, rerouted etc by
> pulseaudio, but it's difficult to mandate that software stop sending audio
> directly to /dev/dsp (well, unless you're a distribution which applies
> patches to upstream software in order to harmonize the experience of its
> users).
> 

I can see the utility of resolvconf and in packages coordinating their
modifications of resolv.conf.  However, I still maintain that there
should be a simple way for the admin to mark resolv.conf in such a way
that no package will modify it.  This should be possible without
resorting to hacks like making resolv.conf immutable.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Darac Marjal]

On Thu, Oct 26, 2017 at 06:44:44AM -0400, Roberto C. Sánchez wrote:

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:

> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything".

`resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
What it does to it is to replace it with a symlink.
After that, it doesn't touch it any morel instead it only modifies the file
that is the target of that symlink.


Given that multiple packages potentially touch/change resolv.conf (at
least resolvconf and the various DHCP clients), would be very useful is
a directive that can be put inside of resolv.conf that informs all such
packages that the file is not to be modified.  That would allow the
admin to avoid having to hunt down all the different packages and
configure them individually to leave /etc/resolv.conf alone.


Actually, there's no need to duplicate the effort. As I understand it, 
resolvconf is basically an optional helper program. Software that 
automatically modifies /etc/resolv.conf should first test for the 
presence of resolvconf (whether that be checking for the configuration 
directory of resolvconf or checking that resolvconf is running or... 
however resolvconf desires to be detected). If resolvconf is available, 
the changes are co-ordinated through resolvconf, otherwise, 
/etc/resolv.conf is modified directly.


The problem is that I don't think that resolvconf can require packages 
to use it. This is similar to other higher-level APIs such as 
pulseaudio. If the software knows to use pulseaudio, then it can get 
mixed, rerouted etc by pulseaudio, but it's difficult to mandate that 
software stop sending audio directly to /dev/dsp (well, unless you're a 
distribution which applies patches to upstream software in order to 
harmonize the experience of its users).




Regards,

-Roberto

--
Roberto C. Sánchez



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: bash usage.

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 04:19:42PM +1100, David Margerison wrote:
> On 26 October 2017 at 11:39,   wrote:
> >
> > According to 'man mountpoint', it returns 0 if something is mounted.
> > So why the complaint from
> >   if [ mountpoint $WorkingDirectory ] ?
> 
> Answered here:
> 
> http://mywiki.wooledge.org/BashPitfalls#if_.5Bgrep_foo_myfile.5D
> 
> http://mywiki.wooledge.org/BashGuide/TestsAndConditionals#Conditional_Blocks_.28if.2C_test_and_.5B.5B.29
> 
> On 26 October 2017 at 12:23, Roberto C. Sánchez  wrote:
> >
> > mountpoint -q $WorkingDirectory
> > if [[ $? = 0 ]]
> 
> That will work, but is ridiculous considering this works by design:
> 
> if mountpoint -q "$wd" ; then
>   echo "$wd is a mountpoint"
> fi
> 

Yes, quite right.  Though, my syntax makes it clear that what is being
tested/evlauated is the exit status, not the output.  I know that the if
evaluates the exit status, but that may not be immediately evident to
someone who is not particularly familiar with shell programming.  

To each his own.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:
> > If Debian developers who are responsible for resolvconf are reading this,
> > and if they actually CARE about making things work correctly and sensibly,
> > then here is yet another proposal: give us a way to QUICKLY and EASILY
> > and RELIABLY tell resolvconf "never do anything".
> 
> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
> What it does to it is to replace it with a symlink.
> After that, it doesn't touch it any morel instead it only modifies the file
> that is the target of that symlink.
> 
Given that multiple packages potentially touch/change resolv.conf (at
least resolvconf and the various DHCP clients), would be very useful is
a directive that can be put inside of resolv.conf that informs all such
packages that the file is not to be modified.  That would allow the
admin to avoid having to hunt down all the different packages and
configure them individually to leave /etc/resolv.conf alone.

Regards,

-Roberto

-- 
Roberto C. Sánchez