date:20191214

On Sb, 14 dec 19, 14:05:01, Jape Person wrote:
> 
> The hostnames and local domain name were used during installation.

Ok, so they are probably configured in /etc/hostname, possibly also 
/etc/hosts.

> The static DHCP addresses are issued by a Luxul XWR-1750 router which
> associates the hostnames with the MAC and IP addresses.

So the same host names are configured also in the router.

> Contents of /etc/resolv.conf:
> 
> search local
> nameserver 208.67.220.220
> 
> I discovered the change a few days ago when I was doing my daily check for
> updates by using SSH to connect to two of the systems. I received the
> following response to the connection command:
> 
> ssh: Could not resolve hostname chip-nuc.local: Name or service not known

Depending also on how you manage the network configuration (ifupdown, 
network-manager, systemd-networkd, etc.) it could be a lot of things. 

My first guess is that something in your resolving infrastructure is now 
treating .local special whereas before it didn't. The other option would 
be that some mDNS package got installed.

You could look at the update logs since the last known previous state 
and see if something sticks out. 

That is, if you want to find out what happened as it seems to me that 
you fixed the immediate problem.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

signature.asc
Description: PGP signature

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Darac Marjal

On 14/12/2019 20:53, ghe wrote:
>> On Fri, Dec 13, 2019, 17:12 Britton Kerin  wrote:
>>
>>> I see from below vote that we're working on dumping other init systems
>>> now as expected.  Luckily I've given up on debian since systemd in the
>>> first place and am in long process of finding a replacement.
> Might want to take a look at the BSDs too, if you'd like to learn some
> new stuff.
>
> I tried a while back (the 'ballot' on the Debian site says not to
> badmouth systemd), and freeBsd was the one I came closest to getting to
> run. Very nice people, and I know a couple admins who swear by it.
>
> I came back to Linux because the disk and Ethernet names in /dev were so
> much easier to deal with in Linux. I see Linux has fixed that now...
>
Why do people get so het up about Ethernet names in Linux? They're
renamable quite easily. So you can have "eth0" or "ens92" or "wlp0s41"
or "internet" or "Local Area Connection 1" if you like. Well, perhaps
not the last one. I'm not sure about spaces.

Re: looking for a replacement for debian since systemd

2019-12-14 Thread ghe

> On Fri, Dec 13, 2019, 17:12 Britton Kerin  wrote:
> 
>> I see from below vote that we're working on dumping other init systems
>> now as expected.  Luckily I've given up on debian since systemd in the
>> first place and am in long process of finding a replacement.

Might want to take a look at the BSDs too, if you'd like to learn some
new stuff.

I tried a while back (the 'ballot' on the Debian site says not to
badmouth systemd), and freeBsd was the one I came closest to getting to
run. Very nice people, and I know a couple admins who swear by it.

I came back to Linux because the disk and Ethernet names in /dev were so
much easier to deal with in Linux. I see Linux has fixed that now...

-- 
Glenn English

Re: apparent change in hostnames on LAN without admin intervention

On Sat 14 Dec 2019 at 13:59:29 -0600, John Hasler wrote:

> Jape writes:
> > I live in a condo where I can see at least three dozen (no kidding)
> > printers advertising their services.
> 
> Take them up on their offer and print something on each of them.

Advertising a service does not mean it an be used by everyone.

-- 
Brian.

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread John Hasler

Jape writes:
> I live in a condo where I can see at least three dozen (no kidding)
> printers advertising their services.

Take them up on their offer and print something on each of them.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: apparent change in hostnames on LAN without admin intervention

On Sat 14 Dec 2019 at 14:05:01 -0500, Jape Person wrote:

> Contents of /etc/resolv.conf:
> 
> search local
> nameserver 208.67.220.220

Why is "search local" required? .local is catered for with
avahi/libnss-mdns.

-- 
Brian.

Re: apparent change in hostnames on LAN without admin intervention


On 12/14/19 8:45 AM, Brian wrote:

On Fri 13 Dec 2019 at 22:04:18 -0500, Jape Person wrote:


On 12/13/19 8:55 PM, David Wright wrote:


But is it possible you've started using avahi/bonjour when previously
you didn't? Or has the router upgraded itself and now knows not to
issue names like that?


I'll check to see if avahi/bonjour are being used, but I haven't done
anything deliberately to start using them. I'm wondering if recent changes
to CUPS may be implicated in some way.


Depends what you mean by recent. :) avahi-daemon has been a Recommends:
of cups-daemon since jessie.


My Brother printer defaults to using
bonjour, but I turned it off because I deemed it to be not particularly
useful to me. It's connected by wire to the router. I live in a condo where
I can see at least three dozen (no kidding) printers advertising their
services. I'm getting ready to switch everything to wired connections.


Bonjour is a network protocol, not a wireless protocol.



Thanks,
JP

Re: apparent change in hostnames on LAN without admin intervention


On 12/14/19 8:02 AM, rhkra...@gmail.com wrote:

On Friday, December 13, 2019 10:04:18 PM Jape Person wrote:

Could this change be due to recent upgrades in software? (I upgrade
every day.) I've reviewed the recent upgrades listed in
/var/log/apt/history.log. I would have thought any deliberate change
of this behavior would have been flagged by listchanges, but I can't
find it.


 From the peanut gallery (I don't know why I sit here): Of course!  That is the
charm of sid / testing -- continuous changes, some of which might break your
system.


I'm just a home user / hobbyist, but this change occurring without any
deliberate administrative action on my part makes the hairs stand up
on my neck -- just a little bit.


Well, I don't know why you're using testing (I don't), but I'm surprised your
hairs on permanently up ;-)



I've been using Sid/testing since long before I established this little network -- at least 12 or 13 
years. I've always enjoyed seeing the changes to Debian as they come down the road. The worst 
problem I remember having was when the framebuffer was introduced. The nVidia graphics card I was 
running in my system at the time had to be appeased. Took maybe two hours to fix.


But this made the old hackles raise because of the possibility that it could have security 
implications. It turns out that this problem has probably been caused by my own misunderstanding of 
proper use of naming conventions.


Thanks,
JP

Re: apparent change in hostnames on LAN without admin intervention

On 12/14/19 3:56 AM, Andrei POPESCU wrote:

On Vi, 13 dec 19, 19:33:51, Jape Person wrote:

Hi folks. Did I miss something?

I've had 3 Sid/testing systems running on the same LAN behind the same
router for just shy of 3 years. Their static IP addresses have always been
issued by the DHCP server on the router. Everything has been copacetic among
the systems, with local and outside name resolution working with no issue.

A little over a week ago the systems stopped being able to access each other
by name. No changes were made in the settings or firmware of the router or
of the local network settings on the systems.

I discovered that all of the hostnames had changed from xx.local to
xx. I've tried to determine the cause of this alteration in the
hostnames on the LAN.

Please provide more info on this, specifically where / how are the
hostnames configured and where / how did you discover they changed.

Do note that .local is typically used by mDNS and in my understanding it
should not be used with a DNS server.

https://en.wikipedia.org/wiki/.local

Kind regards,
Andrei

Hi, Andrei.

The hostnames and local domain name were used during installation.

The static DHCP addresses are issued by a Luxul XWR-1750 router which associates the hostnames with
the MAC and IP addresses.

Contents of /etc/resolv.conf:

search local
nameserver 208.67.220.220

I discovered the change a few days ago when I was doing my daily check for updates by using SSH to
connect to two of the systems. I received the following response to the connection command:

ssh: Could not resolve hostname chip-nuc.local: Name or service not known

I checked to make sure I could connect to everything by IP address, and I checked DNS on the outside
world. Everything looked okay.

On a hunch I tried omitting the .local from the connection command, and it work
on each client.

I figured any time the name of a client changes without deliberate action on the part of the network
admin (however incompetent he may be), that could be a security issue. That's why I asked here.

Thanks,
JP

Re: apparent change in hostnames on LAN without admin intervention


On 12/14/19 4:40 AM, Curt wrote:

On 2019-12-14, Jape Person  wrote:


I could be quite wrong, but I thought that "local" was actually suggested as a 
domain name at one
time by the installer. (And I could be remembering a different distro, though 
I've been using Debian
for a long time -- at least 10 years, I think.) I suppose I just continued to 
use it over the years
out of habit.



https://tools.ietf.org/html/rfc6762

3.  Multicast DNS Names

...

  To remedy this problem [of home computer users generally lacking easy access
  to name creation in the global DNS namespace*], this document allows any
  computer user to elect to give their computers link-local Multicast DNS host
  names of the form: "single-dns-label.local".

...

  This document specifies that the DNS top-level domain ".local." is a
  special domain with special semantics, namely that any fully
  qualified name ending in ".local." is link-local, and names within
  this domain are meaningful only on the link where they originate.

Has RFC 6762 been superseded? Or have I gotten this wrong?



Hi, Curt.

I'm doing some homework. I can see the error of my ways and am planning to change the network 
accordingly.


Still stumped about why .local disappeared from the names, but am obviously not 
married to it.

Thanks,
JP

Re: apparent change in hostnames on LAN without admin intervention


On 12/14/19 1:24 AM, john doe wrote:


Assuming that you are using the router from your ISP, it is possible
that the firmware has been upgraded without your nolage.

One way to prevent this could be (1), that is, use your own
router/server/gateway so you control everything on your LAN.

I use an EMTA modem only from my ISP which is plugged into a perimiter
firewall.

If you can't have an modem from your ISP, look at 'bridgemode'.

If your not comfortable building your server from scratch, you can
simply buy a router that is accepted by your ISP .

In other words, you need to choose one or the other if you go this way:
- Modem connected to router (most flexible of all)
- Combo modem/router in one box (les flexible but is more compact)


If you use DHCP static lease, you should look at what the DHCP server is
providing as hostname and 'TLD', and also in the dhcp client (dhclient'
to see what you get from the DHCP server.

The file '/etc/resolv.conf' should let you know what TLD is sent from
the DHCP server.

Debian shouldn't modify your configuration files '/etc' without your nolage.

Note that the TLD '.lan' is sometime used.

1)  https://www.xfinity.com/support/articles/list-of-approved-cable-modems

--
John Doe



Hi, John Doe.

I'm using my own router behind the modem provided by the ISP. I've never used a router provided by 
an ISP for controlling my network.


I'm using a Luxul XWR-1750 which has been kept on the latest firmware available. Last upgrade was 
done early this year, long before the noted change in names.


The router is set to provide static IP addresses and has the names of each of the systems associated 
with their MAC Addresses and IP Addresses.


Thanks,
JP

[OT] Master Password (was: dropbox security situation)

2019-12-14 Thread l0f4r0

Hi,

13 déc. 2019 à 00:29 de a...@cityscape.co.uk:

> On Thu 12 Dec 2019 at 21:13:06 +0100, l0f...@tuta.io wrote:
>
>> 10 déc. 2019 à 23:11 de a...@cityscape.co.uk:
>>
>> > On Tue 10 Dec 2019 at 22:34:07 +0100, l0f...@tuta.io wrote:
>> >
>> >
>> I've read the documentation. User needs to remember all of
>> this:
>>
>
> > user-name
>
> Real name actually. If you do not know your name you have problems. :)
> Can be set in ~/.bash_rc. Cross this off the list.
>
You are weakening security if you write down or save in specific files some 
elements used for the password generation. But I agree with you, it's not the 
most problematic one ;)

>> site-name
>>
> It is in the address bar of the site you are accessing. google.com,
> debian.org, bt.com etc. What is there to remember? We cross this off
> your list too.
>
As I was explaining before, I'm pretty sure some cases are not so obvious (like 
sites where authentication page is deported/redirected so as time is passing 
you don't remember which "site" you used the first time, same issue with 
websites on multiple domains, sometimes you need to specify the subdomain as 
well...).

>> site-counter
>>
> I'll give you this. But it would be very unusual to want it. The
> default is generally good enough.
>
As discussed after my answer, this is a point.
>> site-template.
>>
You didn't answer to that but that's one more thing to remember especially if 
you needed a custom password initially.

Let's be clear, I think this solution Master Password is original and I'm not 
saying it's impossible to remember all these criteria for most of us. But I 
know it can be problematic for some people, especially site-counter and 
site-template in addition to a master password. Each element is generally easy 
but all of them can be a burden for some people with time passing.

> Many users store their passwords in the cloud. The provider will take
> care of them for you. 
>
Not if there is a master password like any serious password manager.
You can put this file in an encrypted container as well but I agree that makes 
the process heavier.
Best regards,
l0f4r0

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Brad Rogers

On Sat, 14 Dec 2019 14:05:43 +
Jonathan Dowland  wrote:

Hello Jonathan,

>The disassociation between the population of debian-user and the
>project itself,

Is (inevitable|a fact of life).
It's Debian's ball.
It's Debian's game.
They make the rules.

>who's it was), is still eye-opening to me. Not a good thing IMHO.

All distros exercise some degree of separation between users and
creators.

For example, developers (AFAIAA) aren't _required_ to subscribe to any
of the user lists.  Separation.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
I'll tell you something, I think that you should know
Rich Kids - Rich Kids

pgppQQ9yJBk6Q.pgp
Description: OpenPGP digital signature

Re: looking for a replacement for debian since systemd

On Sb, 14 dec 19, 14:05:43, Jonathan Dowland wrote:
> On Sat, Dec 14, 2019 at 08:46:55AM -0500, Roberto C. Sánchez wrote:
> > Discussions have been taking place on debian-vote (specific to this
> > vote), but also debian-project, debian-devel, and various other Debian
> > mailing lists.  For. A. Long. Time.
> 
> The disassociation between the population of debian-user and the project
> itself, as evidenced by the puzzling over that ballot (I wonder who's it
> was), is still eye-opening to me. Not a good thing IMHO.

The subscribers of debian-user are not necessarily representative of the 
entire Debian user community.

Additionally - as you are surely aware - interested Debian users 
(whether subscribers of debian-user or not) are free to follow other 
lists, such as debian-devel-announce:

https://lists.debian.org/debian-devel-announce/2019/10/msg2.html
https://lists.debian.org/debian-devel-announce/2019/11/msg1.html

In my opinion it was probably better that only a few non-Debian Members 
got involved. The discussions were difficult enough.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Help! Borked suspend/hibernate after adding swap partition


Le 14/12/2019 à 16:35, Ottavio Caruso a écrit :

On Sat, 14 Dec 2019 at 13:47, Pascal Hambourg  wrote:


Le 14/12/2019 à 14:20, Ottavio Caruso a écrit :



I've also added:
GRUB_CMDLINE_LINUX_DEFAULT="resume d823f1ee-2e16-4327-b0c1-639f377002bb"


Wrong syntax. It should be "resume=UUID=d823...".
This will override the RESUME value embedded into the initramfs by
update-initramfs.


Thanks. So, if it is already embedded in initramfs, does it make sense
to have that line in /etc/default/grub?


Only if you need to override the resume value embedded in the initramfs.


Shall I just use the default boot option?


Either is fine.

Re: debian-user-digest Digest V2019 #1206

2019-12-14 Thread Phil Wyett

On Sat, 2019-12-14 at 16:20 +, Larry Sapp wrote:
> Unsubscribe
> 
> 



For instructions on subscription/unsubscription.

Please see: https://www.debian.org/MailingLists/#subunsub

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas



signature.asc
Description: This is a digitally signed message part

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread john doe

On 12/14/2019 4:23 PM, Jonas Smedegaard wrote:
> Quoting john doe (2019-12-14 15:54:20)
>> On 12/14/2019 2:36 PM, Curt wrote:
>>> On 2019-12-14, David Wright  wrote:
 On Fri 13 Dec 2019 at 19:33:51 (-0500), Jape Person wrote:
> Hi folks. Did I miss something?

 Perhaps a couple of references:
 https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail
 which points out that any of .home, .mail and .corp are ideal for
 the domain name of a home LAN, and RFC 6762 on Multicast DNS which
 explains why .local is not a good choice.

>>>
>>> I'm trying to fathom why .home would remain ideal for home LAN users
>>> in light of RFC 8375, which replaces the previously advised '.home'
>>> with 'home.arpa' as the default domain name for homenets, the former
>>> being known to often leak out to the root name servers.
>>>
>>> https://tools.ietf.org/html/rfc8375
>>>
>>> Or does RFC 8378 only apply to toasters and the like (what will they
>>> think of next)?
>>>
>>
>> It only applies to devices useing the HNCP protocol.
>
> ...and .home applies to devices abusing protocols: It's unofficial.
>
> "home.arpa" is usable not only with Homenet (a.k.a. HNCP) protocol, but
> equally well without it.
>

Quoting what I missed in the RFC (1):

"   Although this document makes specific reference to [RFC7788], it is
   not intended that the use of 'home.arpa.' be restricted solely to
   networks where HNCP is deployed.  Rather, 'home.arpa.' is intended to
   be the correct domain for uses like the one described for '.home' in
   [RFC7788]: local name service in residential homenets."

1)  https://tools.ietf.org/html/rfc8375#section-1

--
John Doe

Re: looking for a replacement for debian since systemd

2019-12-14 Thread tomas

On Sat, Dec 14, 2019 at 01:23:14PM +0100, Alessandro Vesely wrote:
> On Sat 14/Dec/2019 03:18:39 +0100 Kenneth Parker wrote:
> > 
> > I use Devuan, especially on older hardware.   Works well. 
> 
> 
> Good to know.  For the time being, I see SysV is working.  I'm on old-stable
> Debian.  As, in a few months, it will be time to migrate, I'll have to decide
> on Devuan (current) vs. Buster.  Any recommendation on that?  Will the voted
> resolution shred any light on migration strategies?

Buster here. No systemd. Works a charm.

Some specific packages depend on systemd. Maybe with the time they become
more and more. Maybe not.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Help! Borked suspend/hibernate after adding swap partition

2019-12-14 Thread Ottavio Caruso

On Sat, 14 Dec 2019 at 13:47, Pascal Hambourg  wrote:
>
> Le 14/12/2019 à 14:20, Ottavio Caruso a écrit :

> (...)
> > I've also added:
> > GRUB_CMDLINE_LINUX_DEFAULT="resume d823f1ee-2e16-4327-b0c1-639f377002bb"
>
> Wrong syntax. It should be "resume=UUID=d823...".
> This will override the RESUME value embedded into the initramfs by
> update-initramfs.

Thanks. So, if it is already embedded in initramfs, does it make sense
to have that line in /etc/default/grub? Shall I just use the default
boot option?

-- 
Ottavio Caruso

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread Jonas Smedegaard

Quoting john doe (2019-12-14 15:54:20)
> On 12/14/2019 2:36 PM, Curt wrote:
> > On 2019-12-14, David Wright  wrote:
> >> On Fri 13 Dec 2019 at 19:33:51 (-0500), Jape Person wrote:
> >>> Hi folks. Did I miss something?
> >>
> >> Perhaps a couple of references: 
> >> https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail
> >>  
> >> which points out that any of .home, .mail and .corp are ideal for 
> >> the domain name of a home LAN, and RFC 6762 on Multicast DNS which 
> >> explains why .local is not a good choice.
> >>
> >
> > I'm trying to fathom why .home would remain ideal for home LAN users 
> > in light of RFC 8375, which replaces the previously advised '.home' 
> > with 'home.arpa' as the default domain name for homenets, the former 
> > being known to often leak out to the root name servers.
> >
> > https://tools.ietf.org/html/rfc8375
> >
> > Or does RFC 8378 only apply to toasters and the like (what will they 
> > think of next)?
> >
> 
> It only applies to devices useing the HNCP protocol.

...and .home applies to devices abusing protocols: It's unofficial.

"home.arpa" is usable not only with Homenet (a.k.a. HNCP) protocol, but 
equally well without it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread john doe

On 12/14/2019 2:36 PM, Curt wrote:
> On 2019-12-14, David Wright  wrote:
>> On Fri 13 Dec 2019 at 19:33:51 (-0500), Jape Person wrote:
>>> Hi folks. Did I miss something?
>>
>> Perhaps a couple of references:
>> https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail
>> which points out that any of .home, .mail and .corp are ideal for the
>> domain name of a home LAN, and RFC 6762 on Multicast DNS which
>> explains why .local is not a good choice.
>>
>
> I'm trying to fathom why .home would remain ideal for home LAN users in
> light of RFC 8375, which replaces the previously advised '.home' with
> 'home.arpa' as the default domain name for homenets, the former being
> known to often leak out to the root name servers.
>
> https://tools.ietf.org/html/rfc8375
>
> Or does RFC 8378 only apply to toasters and the like (what will they
> think of next)?
>

It only applies to devices useing the HNCP protocol.

--
John Doe

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Jonathan Dowland


On Sat, Dec 14, 2019 at 08:46:55AM -0500, Roberto C. Sánchez wrote:

Discussions have been taking place on debian-vote (specific to this
vote), but also debian-project, debian-devel, and various other Debian
mailing lists.  For. A. Long. Time.


The disassociation between the population of debian-user and the project 
itself, as evidenced by the puzzling over that ballot (I wonder who's it 
was), is still eye-opening to me. Not a good thing IMHO.


--

Jonathan Dowland

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Roberto C . Sánchez

On Sat, Dec 14, 2019 at 07:58:59AM -0500, rhkra...@gmail.com wrote:
> Where was this survey / vote?  What was the question?  Not very many voters, 
> and the meanings of some of the choices are not very clear to me -- maybe 
> they 
> would be with the added context of knowing the question and/or source of the 
> survey.
> 
> E.g. : "Support portability, without blocking progress" -- support 
> portability 
> of what, and in what way?  And without blocking progress of what?
> 
The vote is ongoing: https://www.debian.org/vote/2019/vote_002

The voters are official Debian Developers.

Voting is open for two more weeks.

Discussions have been taking place on debian-vote (specific to this
vote), but also debian-project, debian-devel, and various other Debian
mailing lists.  For. A. Long. Time.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: unstable: directory pulse in root directory : /pulse where from?

On Sat 14 Dec 2019 at 10:04:34 +0100, Jörg-Volker Peetz wrote:

> Brian wrote on 13/12/2019 21:29:
> > On Fri 13 Dec 2019 at 20:26:32 +0100, Jörg-Volker Peetz wrote:
> > 
> >> Hello,
> >>
> >> does anybody know which package generates the directory /pulse ? This is a 
> >> bug
> >> in unstable I think, but I can't find which package is the culprit.
> > 
> > https://www.debian.org/distrib/packages
> > 
> That doesn't help, the same way as
> 
> $ dpkg -S /pulse
> dpkg-query: no path found matching pattern /pulse
> 
> fails to give any clue.

Of course it helps and gives a clue. It points to investigating what you
suggest below.

> The directory is generated at boot-time. But I wasn't able to find any hint in
> systemd or udev conf-files.

-- 
Brian.

Re: Help! Borked suspend/hibernate after adding swap partition


Le 14/12/2019 à 14:20, Ottavio Caruso a écrit :


$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=d823f1ee-2e16-4327-b0c1-639f377002bb)
I: Set the RESUME variable to override this.

(...)

I've also added:
GRUB_CMDLINE_LINUX_DEFAULT="resume d823f1ee-2e16-4327-b0c1-639f377002bb"


Wrong syntax. It should be "resume=UUID=d823...".
This will override the RESUME value embedded into the initramfs by 
update-initramfs.



to /etc/default/grub

and "sudo update-grub"

but I don't have "/etc/initramfs-tools/conf.d/resume"

Is this file necessary?


No. This file used to define the RESUME variable, but it is not created 
by the installer any more and RESUME can be defined in any other 
configuration file in /etc/initramfs-tools/conf.d or in 
/etc/initramfs-tools/initramfs.conf. If RESUME is not defined, 
update-initramfs will use the active swap.

Re: apparent change in hostnames on LAN without admin intervention

On Fri 13 Dec 2019 at 22:04:18 -0500, Jape Person wrote:

> On 12/13/19 8:55 PM, David Wright wrote:
> 
> > But is it possible you've started using avahi/bonjour when previously
> > you didn't? Or has the router upgraded itself and now knows not to
> > issue names like that?
> 
> I'll check to see if avahi/bonjour are being used, but I haven't done
> anything deliberately to start using them. I'm wondering if recent changes
> to CUPS may be implicated in some way.

Depends what you mean by recent. :) avahi-daemon has been a Recommends:
of cups-daemon since jessie.

>My Brother printer defaults to using
> bonjour, but I turned it off because I deemed it to be not particularly
> useful to me. It's connected by wire to the router. I live in a condo where
> I can see at least three dozen (no kidding) printers advertising their
> services. I'm getting ready to switch everything to wired connections.

Bonjour is a network protocol, not a wireless protocol.

-- 
Brian.

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Brad Rogers

On Sat, 14 Dec 2019 07:58:59 -0500
rhkra...@gmail.com wrote:

Hello rhkra...@gmail.com,

>Where was this survey / vote?  What was the question?  Not very many

Voting closes 27 Dec 2019.
Only Debian Developers are eligible to vote.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Only the wounded remain, the generals have all left the game
Generals - The Damned


pgp8y3yYI35dV.pgp
Description: OpenPGP digital signature

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Jonas Smedegaard

Hi Alessandro,

Quoting Alessandro Vesely (2019-12-14 13:23:14)
> On Sat 14/Dec/2019 03:18:39 +0100 Kenneth Parker wrote:
> > 
> > I use Devuan, especially on older hardware.   Works well. 
> 
> 
> Good to know.  For the time being, I see SysV is working.  I'm on 
> old-stable Debian.  As, in a few months, it will be time to migrate, 
> I'll have to decide on Devuan (current) vs. Buster.  Any 
> recommendation on that?  Will the voted resolution shred any light on 
> migration strategies?

Since this is a Debian list, I recommend to discuss Debian here, and 
consult Devuan mailinglist for details of what they can offer.

The vote currently in Debian will affect _future_ releases of Debian, 
not the current stable release, Buster.

For Debian Buster (regardless of the outcome of the vote) SysV is a 
supported init system: Please do report any flaws you may encounter!

Beware in discussions here and elsewhere to distinguish between these:

 a) running a system with SysV as init system
 b) running a system without systemd installed
 c) running a system without libsystemd0 installed

If you need a), then quite likely Debian Buster is fine for you.

If you need b) and don't need a complex¹ X11/Wayland desktop 
environment, then Debian Buster is likely fine as well.

If you need c) and/or a complex¹ X11/Wayland desktop environment, then 
Debian Buster is most likely no fun for you - might be possible, but you 
will feel alone and bugreports will be harder to debug due to your 
complex setup (in particular your suppressing package recommendations).

¹ In this context, "complex" desktop environments include GNOME, KDE, 
Cinnamon, MATE and more - as a rule of thumb anything which directly or 
indirectly recommends dbus-user-session.

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread Curt

On 2019-12-14, David Wright  wrote:
> On Fri 13 Dec 2019 at 19:33:51 (-0500), Jape Person wrote:
>> Hi folks. Did I miss something?
>
> Perhaps a couple of references:
> https://features.icann.org/addressing-new-gtld-program-applications-corp-home-and-mail
> which points out that any of .home, .mail and .corp are ideal for the
> domain name of a home LAN, and RFC 6762 on Multicast DNS which
> explains why .local is not a good choice.
>

I'm trying to fathom why .home would remain ideal for home LAN users in
light of RFC 8375, which replaces the previously advised '.home' with
'home.arpa' as the default domain name for homenets, the former being
known to often leak out to the root name servers.

https://tools.ietf.org/html/rfc8375

Or does RFC 8378 only apply to toasters and the like (what will they
think of next)?

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: looking for a replacement for debian since systemd

2019-12-14 Thread rhkramer

Where was this survey / vote?  What was the question?  Not very many voters, 
and the meanings of some of the choices are not very clear to me -- maybe they 
would be with the added context of knowing the question and/or source of the 
survey.

E.g. : "Support portability, without blocking progress" -- support portability 
of what, and in what way?  And without blocking progress of what?

On Friday, December 13, 2019 04:55:17 PM Britton Kerin wrote:
> I see from below vote that we're working on dumping other init systems
> now as expected.  Luckily I've given up on debian since systemd in the
> first place and am in long process of finding a replacement.
> 
> Britton
> 
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines
> > =-=-=-=-=-=-=-=- 7b77e0f2-4ff9-4adb-85e4-af249191f27a
> > [ 3 ] Choice 1: F: Focus on systemd
> > [ 1 ] Choice 2: B: Systemd but we support exploring alternatives
> > [   ] Choice 3: A: Support for multiple init systems is Important
> > [   ] Choice 4: D: Support non-systemd systems, without blocking progress
> > [ 2 ] Choice 5: H: Support portability, without blocking progress
> > [   ] Choice 6: E: Support for multiple init systems is Required
> > [   ] Choice 7: G: Support portability and multiple implementations
> > [ 4 ] Choice 8: Further Discussion
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines
> > =-=-=-=-=-=-=-=-

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread rhkramer

On Friday, December 13, 2019 10:04:18 PM Jape Person wrote:
> >> Could this change be due to recent upgrades in software? (I upgrade
> >> every day.) I've reviewed the recent upgrades listed in
> >> /var/log/apt/history.log. I would have thought any deliberate change
> >> of this behavior would have been flagged by listchanges, but I can't
> >> find it.

From the peanut gallery (I don't know why I sit here): Of course!  That is the 
charm of sid / testing -- continuous changes, some of which might break your 
system.

> >> I'm just a home user / hobbyist, but this change occurring without any
> >> deliberate administrative action on my part makes the hairs stand up
> >> on my neck -- just a little bit.

Well, I don't know why you're using testing (I don't), but I'm surprised your 
hairs on permanently up ;-)

Re: looking for a replacement for debian since systemd

2019-12-14 Thread Alessandro Vesely

On Sat 14/Dec/2019 03:18:39 +0100 Kenneth Parker wrote:
> 
> I use Devuan, especially on older hardware.   Works well. 

Good to know.  For the time being, I see SysV is working.  I'm on old-stable
Debian.  As, in a few months, it will be time to migrate, I'll have to decide
on Devuan (current) vs. Buster.  Any recommendation on that?  Will the voted
resolution shred any light on migration strategies?

Best
Ale

Re: Help! Borked suspend/hibernate after adding swap partition


Le 14/12/2019 à 12:26, Ottavio Caruso a écrit :


$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=d823f1ee-2e16-4327-b0c1-639f377002bb)
I: Set the RESUME variable to override this.

I'll reboot and test it and we'll take it from there. (Not sure if
reboot is needed)


Reboot is needed to run the new initramfs.

Re: Help! Borked suspend/hibernate after adding swap partition


Le 14/12/2019 à 10:43, Alexander V. Makartsev a écrit :

Simple swap partition creation is not enough for hibernation to work, it
also has to be configured in initrd. [2]


Despite the file name it is no longer an initrd but an initramfs.


https://wiki.debian.org/Hibernation#Changing_or_moving_the_swap_partition


The advice of reinstalling initramfs-tools given in this wiki page is 
just crazy. You only need to rebuild the initramfs with


update-initramfs -u -k all

However I fail to understand the relationsip between the swap and 
suspend-to-RAM.

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread mick crane


On 2019-12-14 03:04, Jape Person wrote:


I could be quite wrong, but I thought that "local" was actually
suggested as a domain name at one time by the installer. (And I could
be remembering a different distro, though I've been using Debian for a
long time -- at least 10 years, I think.) I suppose I just continued
to use it over the years out of habit.


I had the same thing a while back. I too always thought .local was the 
recommendation and at the time .home was used by a phone company so 
thought it best not to use that.


Seem to remember having trouble tracking down everywhere it is 
mentioned.

good luck

mick
--
Key ID4BFEBB31

Re: Help! Borked suspend/hibernate after adding swap partition

2019-12-14 Thread Alexander V. Makartsev

On 13.12.2019 23:44, Ottavio Caruso wrote:
> Hi,
>
> I'm running LMDE3 (based on Debian oldstable) on  Thinkpad Edge E130.
> I'm not getting much support lately from the Mint forums and that's
> why I'm posting here.
>
> This laptop had been running happily with a mere 4GB RAM and no swap
> until a few weeks ago, when I had to compile a big programme (Liferea)
> and the compiler complained that it was running out of virtual memory.
>
> So I made a 8GB partition and formatted it as swap. This is where all
> problems started. Since then, suspend to ram has stopped working as it
> was (the laptop resumes spontaneously overnight without any
> interactions; the battery drains and the laptop shuts down, creating
> filesystem corruption).
>
> Hibernate doesn't work either. When I open the lid, instead of
> resuming from disk, the laptop just reboots, and, from dmesg I can see
> that it wasn't shut down properly.
>
> This is giving me headaches, as you can imagine. If I manually disable
> swap (sudo swapoff -a), all goes back to normal and suspend works
> beautifully.
>
> At the moment, the only workaround is to disable swap before suspending.
>
> I have the latest kernel. Where do I start troubleshooting? Any ideas?
>
Best way is to start here. [1]
Dealing with powerstates\hibernation could be complicated, because it
depends on many factors.
Simple swap partition creation is not enough for hibernation to work, it
also has to be configured in initrd. [2]


[1] https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html
[2]
https://wiki.debian.org/Hibernation#Changing_or_moving_the_swap_partition

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: apparent change in hostnames on LAN without admin intervention

2019-12-14 Thread Curt

On 2019-12-14, Jape Person  wrote:
>
> I could be quite wrong, but I thought that "local" was actually suggested as 
> a domain name at one 
> time by the installer. (And I could be remembering a different distro, though 
> I've been using Debian 
> for a long time -- at least 10 years, I think.) I suppose I just continued to 
> use it over the years 
> out of habit.
>

https://tools.ietf.org/html/rfc6762

3.  Multicast DNS Names

...

 To remedy this problem [of home computer users generally lacking easy access
 to name creation in the global DNS namespace*], this document allows any
 computer user to elect to give their computers link-local Multicast DNS host
 names of the form: "single-dns-label.local".

...

 This document specifies that the DNS top-level domain ".local." is a
 special domain with special semantics, namely that any fully
 qualified name ending in ".local." is link-local, and names within
 this domain are meaningful only on the link where they originate.

Has RFC 6762 been superseded? Or have I gotten this wrong?

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: User Forgets Aliases

On Sb, 14 dec 19, 04:27:39, Stephen P. Molnar wrote:
> For reasons unknown to me, my user seems to have forgotten aliases in
> .bashrc!
> 
> I find that I have to source the .bashrc use the aliases. This is rather
> inconvenient as I have quite a few aliases that I use all of the time.
> 
> Does anyone haw any idea as to what might be going on here?

What else changed? How are you starting the shell?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: unstable: directory pulse in root directory : /pulse where from?

On Sb, 14 dec 19, 10:04:34, Jörg-Volker Peetz wrote:
> Brian wrote on 13/12/2019 21:29:
> > On Fri 13 Dec 2019 at 20:26:32 +0100, Jörg-Volker Peetz wrote:
> >>
> >> does anybody know which package generates the directory /pulse ? This is a 
> >> bug
> >> in unstable I think, but I can't find which package is the culprit.
> > 
> > https://www.debian.org/distrib/packages
> > 
> That doesn't help, the same way as
> 
> $ dpkg -S /pulse
> dpkg-query: no path found matching pattern /pulse
> 
> fails to give any clue.
> The directory is generated at boot-time. But I wasn't able to find any hint in
> systemd or udev conf-files.

You could try to use inotify to find out what is creating it.

My money is on pulseaudio ;) 

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

User Forgets Aliases

2019-12-14 Thread Stephen P. Molnar


For reasons unknown to me, my user seems to have forgotten aliases in
.bashrc!

I find that I have to source the .bashrc use the aliases. This is rather
inconvenient as I have quite a few aliases that I use all of the time.

Does anyone haw any idea as to what might be going on here?

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: unstable: directory pulse in root directory : /pulse where from?

2019-12-14 Thread Jörg-Volker Peetz

Brian wrote on 13/12/2019 21:29:
> On Fri 13 Dec 2019 at 20:26:32 +0100, Jörg-Volker Peetz wrote:
> 
>> Hello,
>>
>> does anybody know which package generates the directory /pulse ? This is a 
>> bug
>> in unstable I think, but I can't find which package is the culprit.
> 
> https://www.debian.org/distrib/packages
> 
That doesn't help, the same way as

$ dpkg -S /pulse
dpkg-query: no path found matching pattern /pulse

fails to give any clue.
The directory is generated at boot-time. But I wasn't able to find any hint in
systemd or udev conf-files.

Regards,
Jörg.

Re: rsyslog adding old entries again

On Sb, 14 dec 19, 10:28:29, Andrei POPESCU wrote:
> On Vi, 13 dec 19, 20:47:49, mj wrote:
> > Hi Andrei,
> > 
> > So:
> > 
> > > root@pf:~# ps aux | grep rsyslog
> > > root 11250  0.8  3.3 872116 274200 ?   Ssl  15:37   2:26 
> > > /usr/sbin/rsyslogd -n
> > > root 23873  0.0  0.0  12780   968 pts/0S+   20:25   0:00 grep 
> > > rsyslog
> > > root@pf:~# service rsyslog stop
> > > root@pf:~# ps aux | grep rsyslog
> > > root 23909  0.0  0.0  12780  1020 pts/0S+   20:25   0:00 grep 
> > > rsyslog
> > 
> > > root@pf:~# rm -f /usr/local/pf/logs/*
> > > root@pf9:~# lsof | grep /usr/local/pf/logs
> > > snmptrapd 23941   root3w  REG8,1  
> > >   23   67605574 /usr/local/pf/logs/snmptrapd.log
> > 
> > and yes: the file snmptrapd.log is the exception, all other files (20, 25 of
> > them) are gone, remain gone, and are not listed in lsof as open.
> > 
> > Then, when starting rsyslog again, this time in debug mode ("rsyslogd -dn")
> > it shows that it IS in fact writing those logs:
> 
> [...]
>  
> > As you can see from the lines above: these are old log lines from Dec 6.
> 
> On a quick look at the "queued" mode seems to be related. As I'm not 
 ^^^
 the manpage

Sorry, edited it out.

> using rsyslog myself I can't help further.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: apparent change in hostnames on LAN without admin intervention

On Vi, 13 dec 19, 19:33:51, Jape Person wrote:
> Hi folks. Did I miss something?
> 
> I've had 3 Sid/testing systems running on the same LAN behind the same
> router for just shy of 3 years. Their static IP addresses have always been
> issued by the DHCP server on the router. Everything has been copacetic among
> the systems, with local and outside name resolution working with no issue.
> 
> A little over a week ago the systems stopped being able to access each other
> by name. No changes were made in the settings or firmware of the router or
> of the local network settings on the systems.
> 
> I discovered that all of the hostnames had changed from xx.local to
> xx. I've tried to determine the cause of this alteration in the
> hostnames on the LAN.

Please provide more info on this, specifically where / how are the 
hostnames configured and where / how did you discover they changed.

Do note that .local is typically used by mDNS and in my understanding it 
should not be used with a DNS server.

https://en.wikipedia.org/wiki/.local

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Claws mail click on folder - shows zero mails,,,,,

On Sb, 14 dec 19, 09:41:42, Charlie wrote:
> 
>   Hello everyone,
> 
>   Debian Buster - Claws mail version 3.17.3
> 
> The GUI of Claws Mail shows folders containing amounts of read

Did you mean *un*read?

> emails, but when clicked on the numbers vanish and each column shows
> only zeros.

If this is about unread e-mail Claws Mail might mark the e-mails 'read' 
and/or 'old' once you accessed the folder. This should be configurable 
in the settings.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

signature.asc
Description: PGP signature

Re: rsyslog adding old entries again