Re: Debian Releases

[andreimpopescu]

On Vi, 17 mai 19, 17:05:40, Francisco M Neto wrote:
> As the first in a series of (maybe 2) posts about Debian's release cycle, 
> I'vecreated the following post. 
> 
> I would love to receive any feedback on it.
> 
> http://fmneto.com.br/en/en/archives/2019/tracking-busters-release/

Disclaimer: below is based on lurking around Debian (including Developer 
lists) for the past 10 years or so. Feel free to copy-paste whatever you 
need without attribution.

The Release Team is choosing the freeze date after consulting with 
package maintainers. Whenever possible it is chosen to account for the 
different release schedules of the major upstream projects (Linux, 
glibc, etc.).

Considering the amount of software included in Debian this is quite 
challenging. An upstream project may or may not have a (predictable) 
release cycle, stable / long term support / bugfixes only branch, etc. 
which makes it even more difficult.

Depending on the complexity of upstream projects it may take significant 
time to package a new (major) release (think Gnome, KDE, etc.).

Projects on which other software depends (libraries, programming 
languages, etc.) will trigger transitions, which require a rebuild of 
all depending packages at a minimum, but sometimes even a complete 
rewrite of other software (e.g. Python 2 -> 3).

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: DVD Burning speed

[Thomas Schmitt]

Hi,

deloptes wrote:
> What does determine the DVD burning speed? Is it the DVD or the burner or
> both?

The drive decides according to its assessment of the medium and the
speed wish issued by the burn program.

The drive announces a list of possible speeds, depending on the medium.
E.g.:

  $ xorriso -outdev /dev/sr0 -list_speeds
  ...
  Media current: DVD+R/DL
  Media status : is blank
  Media summary: 0 sessions, 0 data blocks, 0 data, 8152m free
  Read speed   :  11079k ,  8.0xD
  Read speed   :   4568k ,  3.3xD
  Read speed L :   4568k ,  3.3xD
  Read speed H :  11079k ,  8.0xD
  Write speed  :   5540k ,  4.0xD
  Write speed  :   3324k ,  2.4xD
  Write speed L:   3324k ,  2.4xD
  Write speed H:   5540k ,  4.0xD

So this drive offers write speed 4.0x and 2.4x, with 1x being 1385 KB/s.
Other drives or media may offer more than just two write speeds.

  Media current: DVD-R sequential recording
  ...
  Write speed  :  22160k , 16.0xD
  Write speed  :  16620k , 12.0xD
  Write speed  :  11080k ,  8.0xD
  Write speed L:  11080k ,  8.0xD
  Write speed H:  22160k , 16.0xD

Those speeds are nominal. I.e. with several media types the drive
will start slower and will slowly accelerate until it reaches the
nominal speed at the outer rim of the medium.


> How can I write DL dvd at 1x speed?

The only certain influence from outside the drive is the data bandwith.
If your program only sends 1385 KB/s to the drive, then it will not be
able to surpass effective speed of 1x.

But this might just mean that the drive waits a few hundred milliseconds
until its buffer is sufficiently full, and then writes at its own chosen
speed until its buffer is empty again.


> I do not have option 1x - it gives me minimum 3x. Why is this so

If it is Brasero, K3B, or Xfburn, then the offer stems from SCSI
commands which inquire above speed list. (Either directly sent from
the burn program or indirectly triggered by asking libburn which then
asks the drive.)

The offer "3x" is somewhat unusual for DVD+R DL. I only know this from
DVD-RAM media. It might indeed stem from a 2.4x list entry.

--

In general i think that the traditional advise to burn at 1x speed is
an urban legend caused by drives at the brink of failure.

Low speed makes low noise. So with with the fast spinning media BD-R,
DVD-R, DVD+R, or CD-R it might be desirable to ask the drive for the
lowest speed available. A speed wish of "1x" should tell it to try its
best to be slow and silent.


Have a nice day :)

Thomas

Re: [Solved - sorta - part 2] Re: how to switch a Debian buster system from systemd to sys-v init

[Jonas Smedegaard]

Quoting Rick Thomas (2019-06-25 03:32:41)
> > On Jun 23, 2019, at 2:24 AM, to...@tuxteam.de wrote:
> > 
> > On Sat, Jun 22, 2019 at 05:45:39PM -0700, Rick Thomas wrote:
> >> 
> >> Purely out of curiosity, I'd like to see what's involved in
> >> switching a Debian buster system from systemd to sysv init.
> > 
> > The short version [1]:
> > 
> >  apt-get install -y sysvinit-core
> 
> So our goal is to start with a working Debian buster system with the 
> Mate desktop using the systemd init, and convert it to a working 
> buster system with no desktop gui, and using the sys-V init.
> 
> As Tomas points out, basically all you should have to do is “apt-get 
> install sysvinit-core”, and the rest should be fully automatic.  This 
> may have worked with Debian stretch, but it’s a bit more complicated 
> with buster.  In particular, there seems to be some parts of the old 
> dbus stuff left around that cause the long pauses I’ve mentioned 
> previously.  This may be a bug and should be reported, but I have no 
> idea what package to report it against, or what a suitable proposed 
> fix would be.
> 
> In any case, the solution I came up with is
> 
> apt-get --purge install -y sysvinit-core dbus- glib-networking- 
> libgtk-3-0-
> apt-get --purge autoremove
> 
> Note the trailing minus-signs on dbus- glib-networking- libgtk-3-0- 
> These packages need to be deleted in the same pass as sysvinit-core is 
> added.

Seems this would work as well, with less collateral damage:

  apt install -y sysvinit-core elogind
  apt --purge autoremove

Would be helpful to know if those experiencing long pause in 
dbus-depending environments had _no_ dbus installed (and actively 
running) or had it running with elogind.


 - 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: DVD Burning speed

[deloptes]

Jude DaShiell wrote:

> The speed in the burning command and the fs parameter.  Needs the right
> amount of memory in it and that's a factor of machine resource
> availability.

but I do not have option 1x - it gives me minimum 3x. Why is this so

Re: New nomeclature of ethernet devices

[The Wanderer]

On 2019-06-25 at 09:28, Michael Stone wrote:

> On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
> 
>> On 2019-06-25 at 08:11, Michael Stone wrote:

>>> It isn't because: 1) the new names are predictable but not
>>> constant, so you can't configure a single default across all
>>> systems
>> 
>> Which seems reasonable to describe as "unpredictable".
> 
> They're perfectly predictable for a given system.

And reasonably unpredictable between systems.

Just reiterating the case where they *are* predictable misses my point
so badly that it almost seems as if it must be intentional.

> The old names also weren't constant, but people didn't seem to care
> as much about the nuances because "that's the way it's always been".
> (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were
> those differences ok but these differences aren't? Familiarity.

No, not just familiarity.

To the best of my awareness, the old names were 100% constant, as long
as you had no more than one interface *of a given type*.

And because you have to deal differently with interfaces of different
types (wireless interfaces need different userspace software from what
you need for wired ones), naming them differently - but still
predictably, in the same sense as before wireless interfaces ever
existed - was useful, because it let you easily distinguish which ones
needed which type of handling.

With the new names, the fact that two interfaces get different name
prefixes (etc.) tells you basically nothing useful about how to handle
them; it just exposes underlying hardware details of some kind, which
you don't actually need to know in order to make effective use of those
interfaces.

>> On a single computer with any number of interfaces of any type, the
>> new names are 100% predictable from one boot to the next. (At least
>> assuming you don't change which slot a given network device is
>> connected to; IIRC that can change the assigned name, in at least
>> some cases.)
> 
> That does change the name, that's the entire point.

With no real benefit as far as I can tell, but yes.

It's also rare even on servers, much less on end-user systems (which
tend to have the network device hardwired into the motherboard, as often
as not). I only included that line for completism's sake - and
apparently it even misses a few cases where things can change even
without doing that, at least one of which I hadn't even considered.

>> Computers with multiple interfaces of the same type are, AFAIK
>> always have been, and IMO are likely to always be, much less common
>> than computers with at most one interface of a given type.
> 
> They're also the only computers where the name actually matters. In
> the simple case it's set at install time and doesn't change, so it
> could be completely random and it wouldn't make a difference.

It matters if you're giving someone directions, with the computer sight
unseen.

Before, you could write directions - or even a script - which just
referenced 'eth0' and/or 'wlan0', and hand the result out Internet-wide,
with assurance that it would work reliably for the large majority of people.

Now, you have to do something to detect the interface(s) and choose the
right one.

>>> They are tremendously helpful if you build servers with multiple
>>> interfaces, or you ever have to swap out a broken nic. If you
>>> have a simple system it gets set once at install time, so who
>>> cares?
>> 
>> Among possibly other things: anyone who has to work with multiple
>> systems with different hardware configurations, which have at most
>> one interface of each type.
>> 
>> Imagine carrying around a live-CD type of environment, for
>> rescue-boot or maintenance-boot purposes, to use on end-user
>> computers. I work in exactly that situation, and adapting - both
>> scripts, and tech habits / expectations / etc. - to the way network
>> interface names now vary between machines has been quite a pain.
> 
> ifquery --list | grep -v lo

And what about when you only want the wired interface, or only the
wireless one, but the machine might have one of each type?

(Plus, I'm pretty sure the environment I work with doesn't have ifquery;
it has ifconfig, but not necessarily much beyond that. The older
versions didn't even have a DHCP client more sophisticated than dhcpcd.
I can add tools to it, but that becomes a pain to maintain, for the same
reasons as adding 'net.ifnames=0' to the kernel command line would be.)

> If there's more than one result, it was going to be hard "the old
> way" also. More portably, something like

Why?

Just using 'eth0' blindly wasn't hard at all, and since we're dealing
with single-user workstations which will never have more than one wired
and one wireless interface, it was a safe assumption to rely on.

> ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") print $2}'
> 
> or 
> 
> ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") {print $2; exit 0}}'
> 
> if you just want the first interface

I want the 

Re: New nomeclature of ethernet devices

[Celejar]

On Tue, 25 Jun 2019 19:35:03 -0400
The Wanderer  wrote:

> On 2019-06-25 at 09:06, Celejar wrote:

...

> > certainly greater than mine - but tab completion works in this context,
> > so you can simply do 'ip addr show dev e', etc.
> 
> Not in my environment, it doesn't. That's presumably because I've
> disabled programmable completion, which I do intentionally because it
> produces results (IIRC relating to directory completion) which I don't like.
> 
> It's still perfectly reasonable to point this out as an approach to
> take, but it would be better to note the prerequisite for it to
> function, even though AFAIK that prerequisite comes enabled by default.

Fair enough - I'm no expert in this area, and I generally use the
defaults with this sort of thing.

Celejar

Re: New nomeclature of ethernet devices

[The Wanderer]

On 2019-06-25 at 09:06, Celejar wrote:

> On Tue, 25 Jun 2019 13:12:58 +0200
>  wrote:
> 
> ...
> 
>> [1] Both are valid decisions, it's your machine, after all. I, for
>>example, went the "old ways", because I do much manual config
>>at the shell, and it's definitely more ergonomical to type
>> 
>>  ip addr show dev eth0
>> 
>>than
>> 
>>  ip addr show dev en&$*#@p?#$%foo
>> 
>>(yes, I'm exaggerating a bit for dramatical effect ;-)
>>But your mileage will almost surely vary.
> 
> Forgive me if I'm pointing out the obvious - your CLI skills are
> certainly greater than mine - but tab completion works in this context,
> so you can simply do 'ip addr show dev e', etc.

Not in my environment, it doesn't. That's presumably because I've
disabled programmable completion, which I do intentionally because it
produces results (IIRC relating to directory completion) which I don't like.

It's still perfectly reasonable to point this out as an approach to
take, but it would be better to note the prerequisite for it to
function, even though AFAIK that prerequisite comes enabled by default.

-- 
   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: New nomeclature of ethernet devices

[Nicholas Geovanis]

On Tue, Jun 25, 2019 at 9:00 AM Dan Purgert  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The "problem" with them was that they apparently weren't consistent
> across boots if you had multiples of the same "type" -- although I can't
> remember that ever happenening, even on crazy frankenboxes that had 3
> and 4 PCI NICs in them (barring moving things around, but these
> "predictable names" change too).
>

I can't remember it ever happening either. The best "intel" I got on the
actual linux shortcoming was that NIC numbering depended
on the order in which the NICs came up and responded at power-on. Although
as you observe, I never actually saw a server come-up
out-of-order like that. Maybe PCI-mounted circuit boards are still
deterministic devices today :-) If you work in a datacenter, you are
configuring many servers at a time and machines are doing the work for you,
so you tie the MAC address to the NIC and that's done at
install time. If you were not doing that or other software you installed
relied on fixed or slowly-changing interface names, there could
be problems.


> --
> |_|O|_|
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
>
>

Re: DVD Burning speed

[Jude DaShiell]

The speed in the burning command and the fs parameter.  Needs the right
amount of memory in it and that's a factor of machine resource
availability.

On Wed, 26 Jun 2019, deloptes wrote:

> Date: Tue, 25 Jun 2019 18:02:29
> From: deloptes 
> To: debian-user@lists.debian.org
> Subject: DVD Burning speed
> Resent-Date: Tue, 25 Jun 2019 22:02:48 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
>
> What does determine the DVD burning speed? Is it the DVD or the burner or
> both?
>
> How can I write DL dvd at 1x speed?
>
> thanks and regards
>
>
>

-- 

DVD Burning speed

[deloptes]

What does determine the DVD burning speed? Is it the DVD or the burner or
both?

How can I write DL dvd at 1x speed?

thanks and regards

Re: New nomeclature of ethernet devices

[Celejar]

On Tue, 25 Jun 2019 13:12:58 +0200
 wrote:

...

> [1] Both are valid decisions, it's your machine, after all. I, for
>example, went the "old ways", because I do much manual config
>at the shell, and it's definitely more ergonomical to type
> 
>  ip addr show dev eth0
> 
>than
> 
>  ip addr show dev en&$*#@p?#$%foo
> 
>(yes, I'm exaggerating a bit for dramatical effect ;-)
>But your mileage will almost surely vary.

Forgive me if I'm pointing out the obvious - your CLI skills are
certainly greater than mine - but tab completion works in this context,
so you can simply do 'ip addr show dev e', etc.

Celejar

Re: Numeric keypad not working on Gnome lock screen

[andreimpopescu]

On Ma, 25 iun 19, 14:56:28, Steven Post wrote:
> 
> Update, I noticed that it shows the same issue when entering a wi-fi
> password, or root password.

Such dialog boxes are kind of special, e.g. to prevent other programs 
from stealing the focus.

This seems to suggest a bug/feature in Gnome/GTK libraries. You might 
want to check the upstream bug reports.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 04:22:54PM -0400, Stefan Monnier wrote:

The one thing I can't understand is why we still don't have "network
interface aliases" (equivalent to symlinks), so that systemd can name my
interface enp2s0 *and* eth0 instead of having to choose between those
two, just like it has no problem naming my SSD /dev/sda and
/dev/disk/by-id/ata-FOOBAR (and a bunch of other names as well).


Because a decision was made decades ago not to access network interfaces via
/dev and changing that now would break a lot.


I wasn't suggesting to move network interfaces into the file-system
(e.g. via device files), but only to add a new feature to create
"network interface aliases".


Yes, but it isn't obvious how those would behave. For filesystems it's a 
well understood concept. Also, for filesystems, it doesn't really matter 
if there are multiple names. For network interfaces, since all of the 
operations require special commands, which interface is returned when 
you enumerate them, etc.? I suspect it would just cause even more 
confusion.

Re: New nomeclature of ethernet devices

[Stefan Monnier]

>>The one thing I can't understand is why we still don't have "network
>>interface aliases" (equivalent to symlinks), so that systemd can name my
>>interface enp2s0 *and* eth0 instead of having to choose between those
>>two, just like it has no problem naming my SSD /dev/sda and
>>/dev/disk/by-id/ata-FOOBAR (and a bunch of other names as well).
>
> Because a decision was made decades ago not to access network interfaces via
> /dev and changing that now would break a lot.

I wasn't suggesting to move network interfaces into the file-system
(e.g. via device files), but only to add a new feature to create
"network interface aliases".


Stefan

Re: cannot install from backports

[Roberto C . Sánchez]

On Tue, Jun 25, 2019 at 04:04:55PM -0400, Brian Cary wrote:
>Greetings!
>As the title says, I can't seem to install anything from backports.
>Example, lets say I need to upgrade Gimp from 2.8 (in stable) to 2.10 (in
>Testing).If I go to [1]https://backports.debian.org/Packages/ I can verify
>that 2.10 is indeed in testing.
>I run this:
>apt -t stretch-backports install gimp
>And my newly installed Debian 9.9 replies:
>gimp is already the newest version (2.8.18-1+deb9u1).
>0 upgraded, 0 newly installed, 0 to remove and 153 not upgraded.
>Which is of course WRONG, because we just looked in Packages and verified
>that 2.10 is in testing.
>What can I do to install Gimp 2.10 from testing?

Testing and backports are two different things.  There is no Gimp
package currently in backports.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: cannot install from backports

[Greg Wooledge]

On Tue, Jun 25, 2019 at 04:04:55PM -0400, Brian Cary wrote:
> I run this:
> *apt -t stretch-backports install gimp*
> And my newly installed Debian 9.9 replies:
> 
> *gimp is already the newest version (2.8.18-1+deb9u1).0 upgraded, 0 newly
> installed, 0 to remove and 153 not upgraded.*
> Which is of course *WRONG*, because we just looked in Packages and verified
> that 2.10 *is* in testing.

Just because a package is in testing doesn't mean a stretch-backport
exists for it.

There are no stretch-backports or jessie-backports packages of gimp at
this time, according to judd in IRC.

cannot install from backports

[Brian Cary]

Greetings!
As the title says, I can't seem to install *any*thing from backports.

*Example*, lets say I need to upgrade *Gimp* from 2.8 (in stable) to 2.10
(in Testing).If I go to https://backports.debian.org/Packages/ I can
*verify* that 2.10 is indeed in testing.

I run this:
*apt -t stretch-backports install gimp*
And my newly installed Debian 9.9 replies:

*gimp is already the newest version (2.8.18-1+deb9u1).0 upgraded, 0 newly
installed, 0 to remove and 153 not upgraded.*
Which is of course *WRONG*, because we just looked in Packages and verified
that 2.10 *is* in testing.

What can I do to install Gimp 2.10 from testing?

Thanks in advance,
--Brian
Also I have run--as *root--**apt update*, and here is my
/etc/apt/sources.list file:














*#copied all this from debian https://wiki.debian.org/SourcesList
deb http://deb.debian.org/debian
 stretch main contrib non-freedeb-src
http://deb.debian.org/debian  stretch main
contrib non-freedeb http://deb.debian.org/debian-security/
 stretch/updates main contrib
non-freedeb-src http://deb.debian.org/debian-security/
 stretch/updates main contrib
non-freedeb http://deb.debian.org/debian 
stretch-updates main contrib non-freedeb-src http://deb.debian.org/debian
 stretch-updates main contrib
non-free#backports added per debian heredeb http://deb.debian.org/debian
 stretch-backports main contrib
non-freedeb-src http://deb.debian.org/debian 
stretch-backports main contrib non-freedeb http://security.debian.org/
 stretch/updates contrib non-free main*

--Brian

Fantastic Fantasy, Curiously Chronicled
Links for all the major platforms -> http://BrianCaryBooks.com

Re: New Hardware + old disks not recognized

[Pascal Hambourg]

Le 24/06/2019 à 01:40, Ross Boylan a écrit :


# update-initramfs -u -k 4.19.0-5-amd64
update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
/usr/share/initramfs-tools/hooks/cryptroot: 64:
/usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts:
No such file
cryptsetup: WARNING: Couldn't determine root device
sed: can't read /proc/cmdline: No such file or directory
/usr/share/initramfs-tools/hooks/cryptroot: 64:
/usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts:
No such file
cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries
 nor crypto modules. If that's on purpose, you may want to uninstall the
 'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs
 integration and avoid this warning.
W: Couldn't identify type of root file system for fsck hook

/proc/mounts isn't accessible in the chroot;


You need to mount /proc. In a chroot, it is often desirable to mount at 
least the /dev, /proc and /sys pseudo-filesystems.



even if it were, it would
not give the mounts appropriate for the system I'm trying to set up.


Why not ? The output of /proc/mounts is not static, it is relative to 
the process reading it.

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 08:23:31PM +0200, Martin S. Weber wrote:

This is not true. I use USB OTGs of embedded devices behind an USB hub,
and the interface names vary between various power cycles of the embedded
devices.


Current default for USB ethernet (AFAIK) is to use enx 
where the NNN is the MAC address. It might be that the fact that 
they're OTG that's confusing something, you might have an alternate 
configuration, or it could be an older version. If it is the current 
version on a clean install I'd simply consider it a bug.



Note the debian box keeps running in the meantime. I can turn on
the device, get interface name #1, then turn it off again, then get
interface name #1i1 (note the i1), then turn it off again, then get
interface name #2 ad nauseatum. This is all but predictable.


The kernel increments the USB device number for each new device. If 
you're using the systemd option to name based on device path rather than 
MAC, it's inevitable that it will change on add/remove because systemd 
is getting the information from the kernel.

Re: New nomeclature of ethernet devices

[Greg Wooledge]

On Tue, Jun 25, 2019 at 01:05:56PM -0500, David Wright wrote:
> However, if you upgraded to stretch, I think you'd have to show that
> you'd allowed the system to preserve the old names, rather than trying
> to circumvent Debian's methods for doing so. Isn't that what you've done?

Upgrades to stretch keep the "eth0" style names.

> I think
> you're meant to live with the old names if you were upgrading, unless
> you know more that the wiki writer who wrote: "Upgrades to Stretch
> will retain the old device names - despite what you will read on the
> web - removing /etc/udev/rules.d/70-local-persistent-net.rules will
> not give you the new names even if followed with a update-initramfs -u
> and update-grub. ( have not yet found the correct Debian incantations
> for this yet?? )"

Had to use google to search the wiki to find out what page you're
talking about here.

Here's when it was added:



For what it's worth, the Buster (not Stretch) release notes say:

  If your system was upgraded from an earlier release, and still uses
  the old-style network interface names that were deprecated with
  stretch (such as eth0 or wlan0), you should be aware that udev in
  buster no longer supports the mechanism of defining their names via
  /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of
  your machine losing networking after the upgrade to buster, it is
  recommended that you migrate in advance to the new naming scheme [...]

This is at

and includes steps to do this.

Re: New nomeclature of ethernet devices

[Martin S. Weber]

Hi!

To derail this discussion a bit more ...

On 2019-06-25 08:46:28, The Wanderer wrote:
> On 2019-06-25 at 08:11, Michael Stone wrote:
> > (...)
> > 1) the new names are predictable but not constant, so you can't
> > configure a single default across all systems
> (...)
> On a single computer with any number of interfaces of any type, the new
> names are 100% predictable from one boot to the next. (At least assuming
> you don't change which slot a given network device is connected to; IIRC
> that can change the assigned name, in at least some cases.)


This is not true. I use USB OTGs of embedded devices behind an USB hub,
and the interface names vary between various power cycles of the embedded
devices. Note the debian box keeps running in the meantime. I can turn on
the device, get interface name #1, then turn it off again, then get
interface name #1i1 (note the i1), then turn it off again, then get
interface name #2 ad nauseatum. This is all but predictable.
(on a side note, systemd-networkd can't properly Match= these things
on name as well).

I file it under "systemd promises not kept", which fills several binders,
shrug, cope with it, and move on.

Regards,
-Martin

Re: New nomeclature of ethernet devices

[David Wright]

On Tue 25 Jun 2019 at 11:09:12 (+0200), Hans wrote:
> Hi Tomas,
> 
> > The moniker for that is "predictable interface names". And you
> > seem to assume that there hasn't been a discussion.
> > 
> > This being Debian, there sure has been one, you just didn't
> > notice :-)
> > 
> Might be, but this does not explain, why there are still scripts and 
> configurations, which are still using the old names. And THAT is the problem.

That would depend on whether they're being *used* on systems that have
interfaces with the newer names. If so, report as a bug.

However, if you upgraded to stretch, I think you'd have to show that
you'd allowed the system to preserve the old names, rather than trying
to circumvent Debian's methods for doing so. Isn't that what you've done?

> > The default (Debian /has/ to settle for one default, since many
> > people installing Debian don't know or care what an interface
> > name is, let alone what the heck a /predictable interface name/
> > is), is "predictable interface names".
> > 
> Yes, I wrote about it. And I also told my opinion about it: If people shall 
> use it, why change to predictable names? That makes no sense.
> 
> > Since not everyone wants or likes that default, you can override
> > it: just just add net.ifnames=0  to your linux commandline (e.g.
> > in /etc/default/grub, like so [1]:
> > 
> I did so some time, but I changed to the new names. However, looks like I 
> have 
> to go back, due to the problems I mentioned. 
> 
> BTW: After an upgrade there suddenly appeared a new line 
> GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
> in /etc/default/grub, without my intervention! Who added this line???

I expect you did, indirectly. It all depends on the conversation you
had whenever Grub was upgraded (eg, Nov 2018) as Grub attempted to
preserve changes made to /etc/default/grub. Do you have any other
files matching /etc/default/grub* ?

After all, you just wrote: "but I changed to the new names" so it
looks as if Grub succeeded in hanging on to that change. I think
you're meant to live with the old names if you were upgrading, unless
you know more that the wiki writer who wrote: "Upgrades to Stretch
will retain the old device names - despite what you will read on the
web - removing /etc/udev/rules.d/70-local-persistent-net.rules will
not give you the new names even if followed with a update-initramfs -u
and update-grub. ( have not yet found the correct Debian incantations
for this yet?? )"

Cheers,
David.

Re: New nomeclature of ethernet devices

[David Wright]

On Tue 25 Jun 2019 at 12:01:31 (-0400), Stefan Monnier wrote:
> > For good description of the problem (unpredictable names) and the logic
> > behind the chosen solution:
> >> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> The one thing I can't understand is why we still don't have "network
> interface aliases" (equivalent to symlinks), so that systemd can name my
> interface enp2s0 *and* eth0 instead of having to choose between those
> two, just like it has no problem naming my SSD /dev/sda and
> /dev/disk/by-id/ata-FOOBAR (and a bunch of other names as well).

Because disks are mounted into the unix filesystem, which understands
links, whereas interfaces are not special files. I would imagine the
kernel is going to have to be persuaded to support this sort of alias.

Cheers,
David.

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 12:01:31PM -0400, Stefan Monnier wrote:

For good description of the problem (unpredictable names) and the logic
behind the chosen solution:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/


The one thing I can't understand is why we still don't have "network
interface aliases" (equivalent to symlinks), so that systemd can name my
interface enp2s0 *and* eth0 instead of having to choose between those
two, just like it has no problem naming my SSD /dev/sda and
/dev/disk/by-id/ata-FOOBAR (and a bunch of other names as well).


Because a decision was made decades ago not to access network interfaces 
via /dev and changing that now would break a lot.

Re: New nomeclature of ethernet devices

[Stefan Monnier]

> For good description of the problem (unpredictable names) and the logic
> behind the chosen solution:
>> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

The one thing I can't understand is why we still don't have "network
interface aliases" (equivalent to symlinks), so that systemd can name my
interface enp2s0 *and* eth0 instead of having to choose between those
two, just like it has no problem naming my SSD /dev/sda and
/dev/disk/by-id/ata-FOOBAR (and a bunch of other names as well).


Stefan

Re: New nomeclature of ethernet devices

[Nate Bargmann]

* On 2019 25 Jun 09:00 -0500, Dan Purgert wrote:
> The "problem" with them was that they apparently weren't consistent
> across boots if you had multiples of the same "type" -- although I can't
> remember that ever happenening, even on crazy frankenboxes that had 3
> and 4 PCI NICs in them (barring moving things around, but these
> "predictable names" change too).

Disclaimer, I am not nor ever have been a professional admin and I've
not dealt with a computer with multiple ethernet NICs.

I seem to recall that on initial installation with some prior releases
that udev would write a rules file that mapped a hardware address to an
interface name.  I hit this a couple of times when moving a disk into
another machine and found that firewall rules didn't work since the NIC
was now eth1 instead of eth0.  A simple edit of the rules file to
comment out the eth0 stanza and renaming eth1 to eth0 and restarting
networking resolved the issue, as I recall.  It may have taken a system
restart instead, I don't remember exactly.

I'm unsure why the udev approach wasn't good enough, but here we are.
On this desktop I restored the old naming convention for various reasons
while the laptop has the new convention.  Both work, but the predictable
names are a bit of random noise to my eyes and require a moment's
parsing.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


signature.asc
Description: PGP signature

Re: New nomeclature of ethernet devices

[Nate Bargmann]

Thanks for explaining the limitation of the udev assignment mechanism
and why the present system was adopted.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


signature.asc
Description: PGP signature

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 01:59:27PM -, Dan Purgert wrote:

Michael Stone wrote:

weren't constant, but people didn't seem to care as much about the
nuances because "that's the way it's always been". (Sometimes it was an
eth, sometimes it was a wlan, etc.) Why were those differences ok but
these differences aren't? Familiarity.


The old names were constant across systems with the same interface(s) --
i.e. an ethernet or a wifi (or both).


Unless you were born with that knowledge (unlikely) someone needed to 
explain why some interfaces had different names than others. Now there's 
just more to explain. (Actually, it's about the same, because other
things we used to have to know have faded away entirely.) Or, in the 
common case, you just don't worry about it. Only if you're in the 
awkward spot of really wanting to do something with a named interface 
based on old knowledge, and aren't willing to learn the new rules, is 
this an issue.



The "problem" with them was that they apparently weren't consistent
across boots if you had multiples of the same "type" -- although I can't
remember that ever happenening, even on crazy frankenboxes that had 3
and 4 PCI NICs in them (barring moving things around, but these
"predictable names" change too).


The problem got increasingly bad as intialization was parallellized, to 
the point that it was *quite noticible* given a large sample set of 
servers. The "solution" was to lock a name to a mac via udev, but that 
just made the system stable as far as which random name was assigned at 
install time. So, for example, on a large set of servers with both 
internal NICs and external NICs, sometimes eth0 would be an internal 1G 
copper interface, and sometimes eth0 would be an external 10G fiber 
interface. This sucked. The "solution" of locking the name to a MAC made 
things even worse, because if you replaced a failed NIC it was 
guaranteed to *not* have the same name on boot unless you went in and 
manually changed the udev config. (And--DANGER WILL ROBINSON--if you 
simply nuked the udev config entirely you were back to a coin flip as to 
which interfaces would have which names and the machine might or might 
not have a working network configuration on startup. This sucked.) Now 
with a large population of servers your built-in NIC will come up as 
something like eno1 and your add-in NIC will be something like ens1f0 
and its second interface will be ens1f1 and even if that looks "weird" 
to some, it's one hell of a lot better than flipping a coin at boot. If 
hardware is replaced (literally swapped) it will come back the same way. 
That's very, very good. And, again, if you're not in a position where 
you want to learn what names will be used in a given situation because 
you're not managing a bunch of servers, then just ignore the interface 
names because they don't matter for simpler systems.



While the new naming has forced "predictability" of some regard, it
comes at the cost of having removed the "predictability" of naming when
communicating about disparate systems. That is, before these names a
"network problem" could be resolved with an interaction along the lines
of:

 (0) (problem description)
 (1) OK, run 'ip a list eth0 | nc termbin.com ' and share the link
 (2) (get the output)
 (3) Ah, there you go - it's only getting an APIPA address, check on
 your DHCP server...

Nowadays, with these "predictable" names, if we tell the other party the
"wrong" name, all we get is an error message that "Device 'en###'
doesn't exist".


That's a good example of "the interface doesn't matter". Just run "ip a" 
instead. If there's only one interface it's simple enough to ignore the 
lo entry and if there's more than one interface *you needed to know that 
anyway* because that could be the source of the problem.

Re: New nomeclature of ethernet devices

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael Stone wrote:
> On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
>>On 2019-06-25 at 08:11, Michael Stone wrote:
>>
>>> On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
>>>
 Might be, but this does not explain, why there are still scripts
 and configurations, which are still using the old names. And THAT
 is the problem.
>>>
>>> It isn't because:
>>> 1) the new names are predictable but not constant, so you can't
>>> configure a single default across all systems
>>
>>Which seems reasonable to describe as "unpredictable".
>
> They're perfectly predictable for a given system. The old names also 

Okay, what's the ethernet interface name of this PC? :)

> weren't constant, but people didn't seem to care as much about the 
> nuances because "that's the way it's always been". (Sometimes it was an 
> eth, sometimes it was a wlan, etc.) Why were those differences ok but 
> these differences aren't? Familiarity.

The old names were constant across systems with the same interface(s) --
i.e. an ethernet or a wifi (or both). 

The "problem" with them was that they apparently weren't consistent
across boots if you had multiples of the same "type" -- although I can't
remember that ever happenening, even on crazy frankenboxes that had 3
and 4 PCI NICs in them (barring moving things around, but these
"predictable names" change too).

While the new naming has forced "predictability" of some regard, it
comes at the cost of having removed the "predictability" of naming when
communicating about disparate systems. That is, before these names a
"network problem" could be resolved with an interaction along the lines
of:

  (0) (problem description)
  (1) OK, run 'ip a list eth0 | nc termbin.com ' and share the link
  (2) (get the output)
  (3) Ah, there you go - it's only getting an APIPA address, check on 
  your DHCP server... 
 
Nowadays, with these "predictable" names, if we tell the other party the
"wrong" name, all we get is an error message that "Device 'en###'
doesn't exist".



-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0SKL0ACgkQjhHd8xJ5
ooFauggAm8fRq0DSKayQ5E2ogdymH1GZCGyA8eleoSR3V3Ml+KE+cWqLldCsfhEa
jiOyZ4JPzr01ORuVsyWBbORNCzGVF779wFp880uANJhOZmTFgphbiOtCOFWnfM4m
lEZj0LhyJL3gojQ+2IIQZZExjHcng8YWF6NXgpbcswvXECY+RyFL15AmM2trTRRU
oZ1MYW9YWHPHcz5ut/m0/GsBTLUMlzRGhy4ead5jhypP9JW2MW6pWEvhVTvRa50I
gQo1tgpUOFH+EWiCO5A44zftnpnXLZeoTtAZ+ieOO1TTwnA7MIN23Ot3CCTDS33Z
JB4+Axu584w9/4/Y1zAYB3v2YYZjOA==
=T01x
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: New nomeclature of ethernet devices

[Greg Wooledge]

On Tue, Jun 25, 2019 at 09:30:59AM -0400, Michael Stone wrote:
> On Tue, Jun 25, 2019 at 09:05:30AM -0400, Greg Wooledge wrote:
> > Debian's defaults are a bit baffling sometimes.  They assumed a mobile
> > device when they decided to put "allow-hotplug" on your wired ethernet
> > interfaces, which breaks everything under the sun on traditional
> > servers or workstations in a work environment.
> 
> How? If the interface is in the system then allow-hotplug and auto are
> synonyms. I have not observed the breakage in hundreds of servers.

With the default "allow-hotplug eth0" (or whatever interface name)
setting, the NFS server will typically come up before DNS lookups are
possible.  When the NFS server starts up, it attempts to look up all
of the client hostnames in /etc/exports.  This is the *one* and *only*
time the NFS server will perform this lookup.  If the lookups fail at
this time, the NFS server will not share anything with anyone, ever.
(Until you notice the problem, and manually restart the NFS server.
A mere exportfs -a will not suffice.  It has to be a full restart.)

NIS has similar issues.  If ypbind can't contact its NIS server when
you try to start it, well, that's just too bad.  ypbind gives up and
dies, and it is not respawned.  I hope you weren't planning to login
to that machine with an NIS account.

I did say *traditional*.  I know all you young kiddies are saying "but but
but but nobody uses NIS or NFS any more, it's like, so OLD, bro, it's from
like a previous DECADE".  Well, they're still in use.  This I promise you.

And allow-hotplug breaks them.  A lot.

(I'm sure there are other services that break when allow-hotplug prevents
them from doing name lookups or whatever at boot time, but these are
the two big ones for me.)

Re: [Solved - sorta - part 2] Re: how to switch a Debian buster system from systemd to sys-v init

[Dan Ritter]

Rick Thomas wrote: 
> 
> In any case, the solution I came up with is
> 
> apt-get --purge install -y sysvinit-core dbus- glib-networking- 
> libgtk-3-0-
> apt-get --purge autoremove
> 
> Note the trailing minus-signs on dbus- glib-networking- libgtk-3-0-  These 
> packages need to be deleted in the same pass as sysvinit-core is added.
> 
> Hope this helps somebody in the future…

I thank you on behalf of my future-self.

-dsr-

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 09:05:30AM -0400, Greg Wooledge wrote:

Debian's defaults are a bit baffling sometimes.  They assumed a mobile
device when they decided to put "allow-hotplug" on your wired ethernet
interfaces, which breaks everything under the sun on traditional
servers or workstations in a work environment.


How? If the interface is in the system then allow-hotplug and auto are 
synonyms. I have not observed the breakage in hundreds of servers.

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:

On 2019-06-25 at 08:11, Michael Stone wrote:


On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:


Might be, but this does not explain, why there are still scripts
and configurations, which are still using the old names. And THAT
is the problem.


It isn't because:
1) the new names are predictable but not constant, so you can't
configure a single default across all systems


Which seems reasonable to describe as "unpredictable".


They're perfectly predictable for a given system. The old names also 
weren't constant, but people didn't seem to care as much about the 
nuances because "that's the way it's always been". (Sometimes it was an 
eth, sometimes it was a wlan, etc.) Why were those differences ok but 
these differences aren't? Familiarity.



On a single computer with any number of interfaces of any type, the new
names are 100% predictable from one boot to the next. (At least assuming
you don't change which slot a given network device is connected to; IIRC
that can change the assigned name, in at least some cases.)


That does change the name, that's the entire point.


Computers with multiple interfaces of the same type are, AFAIK always
have been, and IMO are likely to always be, much less common than
computers with at most one interface of a given type.


They're also the only computers where the name actually matters. In the 
simple case it's set at install time and doesn't change, so it could be 
completely random and it wouldn't make a difference.



They are tremendously helpful if you build servers with multiple
interfaces, or you ever have to swap out a broken nic. If you have a
simple system it gets set once at install time, so who cares?


Among possibly other things: anyone who has to work with multiple
systems with different hardware configurations, which have at most one
interface of each type.

Imagine carrying around a live-CD type of environment, for rescue-boot
or maintenance-boot purposes, to use on end-user computers. I work in
exactly that situation, and adapting - both scripts, and tech habits /
expectations / etc. - to the way network interface names now vary
between machines has been quite a pain.


ifquery --list | grep -v lo

If there's more than one result, it was going to be hard "the old way" 
also. More portably, something like


ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") print $2}'

or 


ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") {print $2; exit 0}}'

if you just want the first interface

Re: New nomeclature of ethernet devices

[Greg Wooledge]

On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
> On a single computer with any number of interfaces of any type, the new
> names are 100% predictable from one boot to the next. (At least assuming
> you don't change which slot a given network device is connected to; IIRC
> that can change the assigned name, in at least some cases.)

At least one person in IRC reported that their interface name changed
after a motherboard firmware upgrade.  So, that's another thing to
watch for.

Debian's defaults are a bit baffling sometimes.  They assumed a mobile
device when they decided to put "allow-hotplug" on your wired ethernet
interfaces, which breaks everything under the sun on traditional
servers or workstations in a work environment.

And then they assumed a multiple-interface server when they decided to
use "net.ifnames=1" in stretch.

So I guess the full assumed target for a Debian installation is a mobile
laptop server with multiple removable ethernet interfaces, which is
not starting any network services at boot time.  (And doesn't need any
non-free firmware to do its job.)

I'm sure such a machine exists somewhere in the universe

Re: Numeric keypad not working on Gnome lock screen

[Steven Post]

On Mon, 2019-06-24 at 22:15 +0200, Steven Post wrote:
> (Please keep me in CC, as I'm not subscribed to the mailing list)
> 
> On Sun, 2019-06-23 at 19:16 +0300, andreimpope...@gmail.com wrote:
> > On Lu, 13 mai 19, 11:29:10, Steven Post wrote:
> > > 
> > > Recently the numeric keypad stopped working on the Gnome lock
> > > screen.
> > 
> > More information would be necessary here, e.g. what Debian version
> > you 
> > are running, if you upgraded any packages recently, etc.
> 
> I'm running Debian 9 (stable), up-to-date.
> 
> > 
> > > When booting, the numlock is in the 'off' state and I can simply
> > > turn
> > > it on by pressing the numlock key'. When I lock the screen
> > > (Super+L),
> > > the numlock light is still on, but pressing a number activates
> > > the
> > > second function (arrow, pg up, etc.), I can get numbers by
> > > holding the
> > > 'shift' key, but not by setting the numlock in either ON of OFF.
> > 
> > Is your keypad working correctly everywhere outside the lock
> > screen?
> 
> Yes, although it is off by default, except after logging into Gnome.
> The problem only exists with the lock screen, it works normally on
> the login
> screen (gdm3).

Update, I noticed that it shows the same issue when entering a wi-fi
password, or root password.

> 
> > 
> > Kind regards,
> > Andrei
> 
> Regards,
> Steven

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

Re: Question on vgconvert

[Steve Keller]

Zdenek Kabelac  wrote:

> Wow :) where you've been hiding for last ~15 years when format V2 exists ;)
> V1 is considered obsolete for very looong time and it's been even dropped
> from support from version 2.03.

That server has indeed been set up rougly 15 years ago.  And until
now, we had no need to convert or resize the PVs.  Now, the machine is
virtualized and we wanted to reduce the disk size to what's actually
needed.

> So you need version 2.02.X.

Fortunately, that is exactly the version Debian stretch still has...

> Operation should be instant (it's only metadata rewrite).
>
> AFAIK no PE should be influenced.

We have done the conversion and it worked like a charm.  Also the following
massive reorganization using pvmove worked fine.

Steve

Re: Giving remaja (teens) group full administrator privileges through sudo - dangerous?

[Greg Wooledge]

On Tue, Jun 25, 2019 at 10:38:10AM +0700, Bagas Sanjaya wrote:
> In this hypothetical scenario, the sudoers rule is applied to ALL systems,
> including production ones, and sysadmins doesn't have proper backups.

On Tue, Jun 25, 2019 at 08:45:13AM -, Curt wrote:
> I'd just get a better hypothetical scenario if I were the OP (they're a
> dime a dozen anyway) because as it stands now his is so completely up
> the wazoo it's really the only sensible advice.

I'm about 30% convinced this is all some sort of elaborate troll.

40% chance this person is just completely incompetent, and these
decisions will mean the end of their employment in this field.

30% chance that it's a language/translation issue, and the actual
intent is not being conveyed correctly, despite repeated requests for
clarification.

(Tt's probably some combination of the three.)

Re: New nomeclature of ethernet devices

[The Wanderer]

On 2019-06-25 at 08:11, Michael Stone wrote:

> On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
> 
>> Might be, but this does not explain, why there are still scripts
>> and configurations, which are still using the old names. And THAT
>> is the problem.
> 
> It isn't because:
> 1) the new names are predictable but not constant, so you can't 
> configure a single default across all systems 

Which seems reasonable to describe as "unpredictable".

The way I usually describe it is as a difference of predictability
"between computers" vs. "between boots".


On a single computer with multiple interfaces of a given type (wired vs.
wireless), the old names are not predictable from one boot to the next.
This is the problem which the new-names approach was designed to solve.

However, on a single computer with at most one interface of a given
type, the names are 100% predictable from one boot to the next.

On multiple computers with at most one interface of a given type, the
names are likewise 100% predictable from one computer to the next.


On a single computer with any number of interfaces of any type, the new
names are 100% predictable from one boot to the next. (At least assuming
you don't change which slot a given network device is connected to; IIRC
that can change the assigned name, in at least some cases.)

However, on multiple computers, the new names are not at all predictable
from one computer to the next, unless the computers have "sufficiently"
identical hardware configurations.


Computers with multiple interfaces of the same type are, AFAIK always
have been, and IMO are likely to always be, much less common than
computers with at most one interface of a given type.

As a result, the problems of unpredictability between boots (with the
old names) are going to be much less commonly encountered than are the
problems of unpredictability between computers (with the new ones).

It is my opinion that the default should be set to produce predictable
results in the more common case, both because it's easier to change away
from the default on the smaller number of systems involved in the less
common case, and because those computers (being more likely to be
servers, et cetera) are more likely to be run by people who are skilled
enough to figure out how to change away from the default.


Regardless, IMO calling *either* approach "predictable network interface
names" is inappropriate, because they're both unpredictable in different
circumstances; all either one does is move the unpredictability around
as compared with the other.

>>> The default (Debian /has/ to settle for one default, since many 
>>> people installing Debian don't know or care what an interface 
>>> name is, let alone what the heck a /predictable interface name/ 
>>> is), is "predictable interface names".
>>> 
>> Yes, I wrote about it. And I also told my opinion about it: If
>> people shall use it, why change to predictable names? That makes no
>> sense.
> 
> They are tremendously helpful if you build servers with multiple 
> interfaces, or you ever have to swap out a broken nic. If you have a
> simple system it gets set once at install time, so who cares?

Among possibly other things: anyone who has to work with multiple
systems with different hardware configurations, which have at most one
interface of each type.

Imagine carrying around a live-CD type of environment, for rescue-boot
or maintenance-boot purposes, to use on end-user computers. I work in
exactly that situation, and adapting - both scripts, and tech habits /
expectations / etc. - to the way network interface names now vary
between machines has been quite a pain.

(Setting net.ifnames=0 for that environment would be possible, but a
pain to maintain because of the way that environment gets updated from
upstream, who are outside of our control and would reject requests to
change their default because they need to support the
multiple-interfaces configuration out of the box for people who don't
have the skill to make the reverse change.)

-- 
   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: New nomeclature of ethernet devices

[Curt]

On 2019-06-25, Hans  wrote:
>
> When it was decided to use new names, then ALL related packages should be 
> adapted to the new style. If it is not done, this is a bug. More over, IMO it 
> is a critical release bug. For a new release I expect those things fixed. It 
> is 
> a thing of quality.

How about coughing up the actual names, as you seem not adverse to
firing off an email or three---for those of us here in the balcony
seats---of a couple of the packages/programs with critical release bugs
related to the switch to predictable interface names to which you are
alluding.

Thanks in advance.

Re: New nomeclature of ethernet devices

[Michael Stone]

On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:

Might be, but this does not explain, why there are still scripts and
configurations, which are still using the old names. And THAT is the problem.


It isn't because:
1) the new names are predictable but not constant, so you can't 
configure a single default across all systems 
2) most software doesn't care about interfaces, so doesn't need to have 
an interface configured
3) software that does care about interfaces generally needs some 
additional configuration, so the defaults aren't relevant
4) if there are isolated exceptions, they can be dealt with as they are 
noticed. if software is used so little that nobody has noticed that it's 
not working, there are probably bigger issues with the package.



The default (Debian /has/ to settle for one default, since many
people installing Debian don't know or care what an interface
name is, let alone what the heck a /predictable interface name/
is), is "predictable interface names".


Yes, I wrote about it. And I also told my opinion about it: If people shall
use it, why change to predictable names? That makes no sense.


They are tremendously helpful if you build servers with multiple 
interfaces, or you ever have to swap out a broken nic. If you have a 
simple system it gets set once at install time, so who cares?

Re: New nomeclature of ethernet devices

[tomas]

On Tue, Jun 25, 2019 at 01:36:23PM +0200, Hans wrote:
> > You mean *your* old files or those coming with *new* Debian packages?
> Here I mean *new* Debian packages. What I want to say is this: Upgrading to a 
> new package version should not destroy the system or force the admin to edit 
> many configurations manually. 

I see. Then, these are bugs.

> When it was decided to use new names, then ALL related packages should be 
> adapted to the new style [...]

I'm sure Debian developers tried to do that. But they may have missed
something. Coming up with concrete, reproducible examples would be now
the thing to do.

[...]

> P.S. I will stop talking this thematic on this list. Feel free to write to me 
> directly. 

This won't be possible, since your mail provider bounces my mails
(I already complained at them).

Cheers
-- t


signature.asc
Description: Digital signature

Re: New nomeclature of ethernet devices

[Hans]

> You mean *your* old files or those coming with *new* Debian packages?
Here I mean *new* Debian packages. What I want to say is this: Upgrading to a 
new package version should not destroy the system or force the admin to edit 
many configurations manually. 

When it was decided to use new names, then ALL related packages should be 
adapted to the new style. If it is not done, this is a bug. More over, IMO it 
is a critical release bug. For a new release I expect those things fixed. It is 
a thing of quality.

My intention was, to point to a problem, which for me, that no one cared and 
which was noticed by nobody. To say: "We don't care, just go back to the old 
style or file a bug for every package" is easy. 

On the other hand: I do not care for new installations, I care for existing 
installations. I do not care for my few systems, which I am using. I am 
thinking of someone running hundreds or thousands of systems.

As I said, I find a solution, I always do.

Ok, let me tell my last words: You do not need to care anymore. I showed up 
the problem, described it and for myself I got a solution. So: Not my problem.

Thank you for the feedback.

Best regards

Hans

P.S. I will stop talking this thematic on this list. Feel free to write to me 
directly. 

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

Re: New nomeclature of ethernet devices

[tomas]

On Tue, Jun 25, 2019 at 12:56:45PM +0200, Hans wrote:
> Hi Richard and Tomas,
> 
> maybe I was not clear enough. So I try to explain again:

[...]

> The point is: There are many OLD files from FORMER installations of times 
> ago, 

You mean *your* old files or those coming with *new* Debian packages?

In the former case, it's obviously on you to decide which way
you go (predictable filenames + fix your configs versus keep
the "old way" [1]). In the second, it's obviously a bug in the
package: if you spot one of those, you might want to file a bug
report.

Cheers

[1] Both are valid decisions, it's your machine, after all. I, for
   example, went the "old ways", because I do much manual config
   at the shell, and it's definitely more ergonomical to type

 ip addr show dev eth0

   than

 ip addr show dev en&$*#@p?#$%foo

   (yes, I'm exaggerating a bit for dramatical effect ;-)
   But your mileage will almost surely vary.

-- t


signature.asc
Description: Digital signature

Re: New nomeclature of ethernet devices

[Hans]

Hi Richard and Tomas,

maybe I was not clear enough. So I try to explain again:

When it is recommended to use the predictable names, then please explain me 
(and all the other people), why the heck are configuration files and scripts 
still using the old names. 

I do not want to know, WHY these are used, and what are the CONs and PROs, and 
how to disable it, I already know this. 

The point is: There are many OLD files from FORMER installations of times ago, 
which are NOT compatible with predictable names. THAT is the point. And THAT 
should be fixed (IMHO).

Hope, that makes my point of arguing clearer. However, if this is not 
interesting for anyone, just let me know and I will stop argumenting in this 
discussion at once. No problem for me, I will find a solution for me. I always 
do.

Best regards

Hans



And please


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

Re: New nomeclature of ethernet devices

[tomas]

On Tue, Jun 25, 2019 at 05:07:07AM -0500, Richard Owlett wrote:
> On 06/25/2019 03:49 AM, to...@tuxteam.de wrote:
> >
> >[1] 
> >https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
> >You do read the release notes, don't you? ;-)
> 
> That reference leads to two pages worth reading by fellow newbies.
> 
> For good description of the problem (unpredictable names) and the
> logic behind the chosen solution:
> >https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> That pages lacked explanatory examples. The fine grained details are
> available at:
> >https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
> 
> Both are very well written.

Thanks for clarifications

Cheers
-- t


signature.asc
Description: Digital signature

Re: New nomeclature of ethernet devices

[Richard Owlett]

On 06/25/2019 03:49 AM, to...@tuxteam.de wrote:


[1] 
https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
You do read the release notes, don't you? ;-)


That reference leads to two pages worth reading by fellow newbies.

For good description of the problem (unpredictable names) and the logic 
behind the chosen solution:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/


That pages lacked explanatory examples. The fine grained details are 
available at:

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html


Both are very well written.

Re: New nomeclature of ethernet devices

[Hans]

Hi Tomas,

> The moniker for that is "predictable interface names". And you
> seem to assume that there hasn't been a discussion.
> 
> This being Debian, there sure has been one, you just didn't
> notice :-)
> 
Might be, but this does not explain, why there are still scripts and 
configurations, which are still using the old names. And THAT is the problem.

> The default (Debian /has/ to settle for one default, since many
> people installing Debian don't know or care what an interface
> name is, let alone what the heck a /predictable interface name/
> is), is "predictable interface names".
> 
Yes, I wrote about it. And I also told my opinion about it: If people shall 
use it, why change to predictable names? That makes no sense.

> Since not everyone wants or likes that default, you can override
> it: just just add net.ifnames=0  to your linux commandline (e.g.
> in /etc/default/grub, like so [1]:
> 
I did so some time, but I changed to the new names. However, looks like I have 
to go back, due to the problems I mentioned. 

BTW: After an upgrade there suddenly appeared a new line 
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
in /etc/default/grub, without my intervention! Who added this line???
 
>   GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
> 
> don't forget to run update-grub afterwards, ask here if unsure,
> proceed with care, etc. etc.).

Of course. :)
> 
> Cheers
> 
> [1]
> https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrad
> ing... You do read the release notes, don't you? ;-)
> -- t

IMO the handling of names is still half-baked and we should have a look at it.

Best 

Hans

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

Re: New nomeclature of ethernet devices

[tomas]

On Tue, Jun 25, 2019 at 10:03:48AM +0200, Hans wrote:
> Hi folks,

[...]

> The issue:
> Since some time the ethernet devices like wlan0 or eth0 got new names, like 
> wlp2s0 or enp0s9 or similar.
> 
> Whilst this is no problem to change these manually in 
> /etc/network/interfaces, 
> there are a lot of programms with configration files or just scripts, which 
> are 
> still using the old names.

The moniker for that is "predictable interface names". And you
seem to assume that there hasn't been a discussion.

This being Debian, there sure has been one, you just didn't
notice :-)

The default (Debian /has/ to settle for one default, since many
people installing Debian don't know or care what an interface
name is, let alone what the heck a /predictable interface name/
is), is "predictable interface names".

Since not everyone wants or likes that default, you can override
it: just just add net.ifnames=0  to your linux commandline (e.g.
in /etc/default/grub, like so [1]:

  GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"

don't forget to run update-grub afterwards, ask here if unsure,
proceed with care, etc. etc.).

Cheers

[1] 
https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
   You do read the release notes, don't you? ;-)
-- t


signature.asc
Description: Digital signature

Re: Giving remaja (teens) group full administrator privileges through sudo - dangerous?

[Curt]

On 2019-06-25, Aidan Gauland  wrote:
>>
>> In this hypothetical scenario, the sudoers rule is applied to ALL
>> systems, including production ones, and sysadmins doesn't have proper
>> backups.
> OK, not having a (good) backup system is definitely bad.  You should
> always have that even if your security is very tight, in case something
> slips through, or an admin makes a mistake.

I'd just get a better hypothetical scenario if I were the OP (they're a
dime a dozen anyway) because as it stands now his is so completely up
the wazoo it's really the only sensible advice.

New nomeclature of ethernet devices

[Hans]

Hi folks,

there is a little thing, we should either discuss or I should be pointed to 
your solution.

The issue:
Since some time the ethernet devices like wlan0 or eth0 got new names, like 
wlp2s0 or enp0s9 or similar.

Whilst this is no problem to change these manually in /etc/network/interfaces, 
there are a lot of programms with configration files or just scripts, which are 
still using the old names.

Looking to "/etc/init.d/ifplugd" for examle, still eth* and wlan* is used. 
This is only one example. 

So, IMO, this is a problem, which should be discussed. Maybe this is no 
problem whith a fresh installation, but many of us have systems running since 
years. 

The solutions coiming in my mind, are either to change scripts and config 
files, 
which may read the existing devices (dicovered by the kernel) and then add 
these into its configuration files.

The second solution, is just to add a kernel paramter, which renames the 
devices (net.ifrenames=0?). But doing so, great, then you do need not the 
special kernel function for the devices. I think, this is not the good idea.

The third solution, coming into my mind, is to manually edit all the 
configurations and the scripts, too. Also no good idea, because after an 
update, all scripts and "maybe" configuration files are overwritten.

Thinking of all solutions, there is not a really good one. The easiest is, 
adding the kernel parameter into /etc/default/grub and forget about the rest. 
Is this really, what we want? If so, then the kernel function (finding devices 
and name them) should be removed from the kernel. Unnecessary code.

But: Maybe I am all the way wrong, and I have something not well understood. 
Then please point me to my mistakes. If not, we should find a better solution 
than my suggestions.

Thank you for reading this and your clemency.

Best regards

Hans



 

  

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

Re: Giving remaja (teens) group full administrator privileges through sudo - dangerous?

[Aidan Gauland]

On 25/06/19 3:38 PM, Bagas Sanjaya wrote:
> On 24/06/19 06.27, Aidan Gauland wrote:
>
>> I can't really offer an opinion on whether it is dangerous without a
>> more detailed hypothetical scenario, but I would say that is
>> overbroad, and this rule should be narrowed down to only allow
>> running certain commands via sudo as required for this group to
>> perform their work.
>
> In this hypothetical scenario, the sudoers rule is applied to ALL
> systems, including production ones, and sysadmins doesn't have proper
> backups.
OK, not having a (good) backup system is definitely bad.  You should
always have that even if your security is very tight, in case something
slips through, or an admin makes a mistake.

Re: How can we check that a compressed file is rsyncable ?

[Curt]

On 2019-06-25, rhkra...@gmail.com  wrote:
> On Mon, Jun 24, 2019 at 12:42:37PM -, Curt wrote:
>> On 2019-06-22, Andy Smith  wrote:
>> > I am not aware of any other compression tool that offers to do what
>> > gzip's --rsyncable option does, but I owuld be interested if there
>> > are some that I overlooked.
>> 
>> zstd introduced an '--rsyncable' flag with version 1.3.8 (available from
>> stretch-backports for those using stable).
>
> I guess I'd like to know what makes a compressed file rsyncable -- I guess 
> that 
> means it is compressed so that a single change doesn't change many or all 
> parts of the file.
>
> If an encryption method attempted to do the same thing (to create an 
> rsyncable 
> encrypted file), that might compromise the encryption of the file.

There's something called rsyncrypto of which you may not have heard (in
a Debian repository near you).

The home page, however, is MIA (which may or may not be weird or disquieting).

http://rsyncrypto.lingnu.com

I get (after a browser warning because there's no s after the p):

 No site configured at this address

>From the man:

 rsyncrypto  is  a  utility  that  encrypts a file (or a directory structure) in
 a way that ensures that local changes to the plain text file will result  in
 local  changes  to  the cipher  text  file.  This,  in turn, ensures that doing
 rsync to synchronize the encrypted files to another machine will have only a
 small impact on rsync's wire efficiency.

> (And, I think it has been at least implied in the thread, that any file can 
> be 
> transferred by rsync -- to be rsyncable I assume (I know) means that there 
> are 
> enough unchanged "segments" of the file after a change to the unencrypted 
> file 
> that the rsync algorithm is worthwhile (the computational cost of the rsync 
> algorithm is paid back in terms of a shorter overall transfer time for the 
> file). 
>

Hddtemp vs smartctl

[basti]

Hello,
I have a toshiba usb drive. With smartctl i can see some values, hddtemp
show nothing:

smartctl -i /dev/sdc; smartctl -a /dev/sdc | grep 194
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-9-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model: TOSHIBA MQ01ACF050
Serial Number:xxx
LU WWN Device Id: 5 39 653f02365
Firmware Version: AV001U
User Capacity:500.107.862.016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate:7200 rpm
Form Factor:  2.5 inches
Device is:Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 3.0 Gb/s (current: 3.0 Gb/s)
Local Time is:Tue Jun 25 09:29:26 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

194 Temperature_Celsius 0x0022   100   100   000Old_age   Always
  -   39 (Min/Max 18/48)


hddtemp /dev/sdc --debug

= hddtemp 0.3-beta15 ==
Modell: TOSHIBA


I also try to add the drive to database, with the same result.

hddtemp /dev/sdc --debug --drivebase| grep Tos

MK4313MAT   |   220 | Toshiba MK4313MAT
TOSHIBA MK1517GAP   | 0 | Toshiba MK1517GAP
TOSHIBA MK2018GAS   |   226 | Toshiba MK2018GAS
TOSHIBA MK3017GAP   | 0 | Toshiba MK3017GAP
TOSHIBA MQ01ACF050  |   194 | Toshiba MQ01ACF050

Re: Giving remaja (teens) group full administrator privileges through sudo - dangerous?

[mick crane]

On 2019-06-25 04:38, Bagas Sanjaya wrote:

On 24/06/19 06.27, Aidan Gauland wrote:

I can't really offer an opinion on whether it is dangerous without a 
more detailed hypothetical scenario, but I would say that is 
overbroad, and this rule should be narrowed down to only allow running 
certain commands via sudo as required for this group to perform their 
work.


In this hypothetical scenario, the sudoers rule is applied to ALL
systems, including production ones, and sysadmins doesn't have proper
backups.


I've concluded that you are asking for assistance with some artistic 
idea applying anarchist political theory to TV film production but are 
confusing production method with production tools.
When film/ tape was flammable an editor wouldn't let a random person 
with a flame thrower into his editing room likewise a computer whose 
function might be video editing is a tool of many delicate parts and if 
some part of it is broken then it likely will stop working.


mick
--
Key ID4BFEBB31