Re: How Buster release may affect Unstable?

[tomas]

On Mon, Jul 01, 2019 at 11:27:40PM +0200, Ansgar wrote:
> Default User  writes:
> > Or something like
> > systemd infects the distribution or its rate of metastasis accelerates,

This was definitely toxic...

> I think we should make systemd mandatory; it would help make Debian a
> more welcoming distribution by making toxic people hopefully finally go
> away.

... and this was as much.

Please, folks. Just be civilised. Can't be that hard.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Fwd: alternative Firmware for BMC's

[Stefan K]

Hello,

a BMC or IPMI interface is a controller which is described here [1]

> But apparently you can replace BMC's 'firmware' with your own, something
> that OpenBMC tries to achieve. Main problem is - there are many
> BMC/ILOM/ILO, and OpenBMC targets a few of them. I'd give my hand for a
> sensible replacement of Sun's ILOM 'firmware', but I'm not aware of any.
Yes, but in this post i talk about Supermicro servers/mainboards and I try to 
find something for Aspeed AST2500 chips, but there is nothing :-(

But thanks, it looks like that the author made a mistake, maybe..


[1] 
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#IPMI_components



On Monday, July 1, 2019 3:48:50 PM CEST rhkra...@gmail.com wrote:
> I don't know how many people are aware of what the BMC is / does -- after a 
> little googling, my tentative understanding is that this is the "extra" 
> miroprocessor that is now included in some (Intel and maybe AMD?) CPUs?
> 
> What are you trying to do with it?
> 
> If you're setting up a computer that happens to have one of those, can you 
> just ignore it, or must it do something to allow the main CPU to run?
> 
> On Monday, July 01, 2019 04:27:48 AM Stefan K wrote:
> > Hello everybody,
> > 
> > So I don't get any answers from the debian-user-german mailinglist I ask
> > you ;)
> > 
> > short question: when I read [1] (sorry just in german), it says that
> > several vendors install their own BMC software up there. So I ask myself
> > which one? OpenBMC doesn't really seem to work yet and I can't think of
> > anything else. I've already written to the author (several times) but
> > without reaction. :( Do you have any idea what alternatives there are
> > (ideally which ones work)?
> > 
> > [1]
> > https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-
> > rootkit-1901-138956.html
> > 
> > best regards
> > Stefan
> > 
> > --  Forwarded Message  --
> > 
> > Subject: alternative Firmware für BMC's
> > Date: Tuesday, June 25, 2019, 3:21:03 PM CEST
> > From: Stefan K 
> > To: debian-user-ger...@lists.debian.org
> > 
> > Hallo in die Runde,
> > 
> > kurze Frage: wenn ich [1] lese, steht dort dass diverse Anbieter ihre
> > eigene BMC-Software rauf klatschen. Da stellt sich mir die Frage welche
> > denn? OpenBMC scheint noch nicht wirklich zu gehen und ansonsten fällt mir
> > da nichts ein. Ich hab auch schon den Autor angeschrieben (mehrmals)
> > jedoch ohne Reaktion. :( Habt ihr denn dazu eine Idee was es da denn an
> > Alternativen gibt (idealerweise welche die auch funktionieren)?
> > 
> > [1]
> > https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-
> > rootkit-1901-138956.html
> > 
> > MfG
> > Stefan
> > 
> > 
> > -
> 

Re: How Buster release may affect Unstable?

[tomas]

On Mon, Jul 01, 2019 at 11:51:10PM +0200, Matthew Crews wrote:
> On 7/1/19 10:24 AM, Default User wrote:
> > Hi.
> > 
> > Easy question, maybe hard to answer . . . 
> > 
> > Is someone has an existing conventional Unstable setup (nothing exotic
> > in hardware or software), what if any special actions should be taken
> > before, during, or after the impending release of the new Stable?
> 
> Be ready for Unstable to become...well, unstable again.
> 
> Right now Unstable is mostly frozen due to the imminent release of
> Buster. Shortly (immediately?) after Buster is released, Unstable will
> be unfrozen, and the good 'ol Debian Sid everyone knows and loves will
> be back.

Officially, only "testing" gets really frozen, but still unstable might
be seen as "slush" during that time. Quoting from [1]:

  6.5.1 What about "testing"? How is it `frozen'?

  When the "testing" distribution is mature enough, the release
  manager starts `freezing' it [...]

  After a while, the "testing" distribution becomes truly `frozen'
  [...]

  When a "testing" release becomes `frozen', "unstable" tends
  to partially freeze as well. This is because developers are
  reluctant to upload radically new software to unstable

So expect those "reluctant developers" to go a bit wild after
the release :-)

Cheers

[1] https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-frozen

-- t


signature.asc
Description: Digital signature

Re: How Buster release may affect Unstable?

[Joe]

On Tue, 2 Jul 2019 09:21:59 +0200
 wrote:

> On Mon, Jul 01, 2019 at 11:51:10PM +0200, Matthew Crews wrote:
> > On 7/1/19 10:24 AM, Default User wrote:  
> > > Hi.
> > > 
> > > Easy question, maybe hard to answer . . . 
> > > 
> > > Is someone has an existing conventional Unstable setup (nothing
> > > exotic in hardware or software), what if any special actions
> > > should be taken before, during, or after the impending release of
> > > the new Stable?  
> > 
> > Be ready for Unstable to become...well, unstable again.
> > 
> > Right now Unstable is mostly frozen due to the imminent release of
> > Buster. Shortly (immediately?) after Buster is released, Unstable
> > will be unfrozen, and the good 'ol Debian Sid everyone knows and
> > loves will be back.  
> 
> Officially, only "testing" gets really frozen, but still unstable
> might be seen as "slush" during that time. Quoting from [1]:
> 
>   6.5.1 What about "testing"? How is it `frozen'?
> 
>   When the "testing" distribution is mature enough, the release
>   manager starts `freezing' it [...]
> 
>   After a while, the "testing" distribution becomes truly `frozen'
>   [...]
> 
>   When a "testing" release becomes `frozen', "unstable" tends
>   to partially freeze as well. This is because developers are
>   reluctant to upload radically new software to unstable
> 
> So expect those "reluctant developers" to go a bit wild after
> the release :-)
> 

They haven't exactly been quiet during the freeze. Tens of megabytes a
day on my workstation, often over 100. But yes, major architecture
changes tend to be kept in the pipeline until after release.

-- 
Joe

[no subject]

[Bapi Dey]

sudo apt update
Ign:1 http://deb.debian.org/debian stretch InRelease
Hit:2 http://security.debian.org/debian-security stretch/updates InRelease
Get:3 http://deb.debian.org/debian stretch-updates InRelease [90.3 kB]
Err:2 http://security.debian.org/debian-security stretch/updates InRelease
  The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 9D6D8F6BC857C906 NO_PUBKEY 8B48AD6246925553
Err:3 http://deb.debian.org/debian stretch-updates InRelease
  The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 7638D0442B90D010
Hit:4 http://deb.debian.org/debian stretch Release
Err:5 http://deb.debian.org/debian stretch Release.gpg
  The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
NO_PUBKEY EF0F382A1A7B6500
Fetched 90.3 kB in 1s (78.1 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is
not updated and the previous index files will be used. GPG error:
http://security.debian.org/debian-security stretch/updates InRelease: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 9D6D8F6BC857C906 NO_PUBKEY 8B48AD6246925553
W: An error occurred during the signature verification. The repository is
not updated and the previous index files will be used. GPG error:
http://deb.debian.org/debian stretch-updates InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 7638D0442B90D010
W: An error occurred during the signature verification. The repository is
not updated and the previous index files will be used. GPG error:
http://deb.debian.org/debian stretch Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY
8B48AD6246925553 NO_PUBKEY 7638D0442B90D010 NO_PUBKEY EF0F382A1A7B6500
W: Failed to fetch
http://security.debian.org/debian-security/dists/stretch/updates/InRelease
 The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 9D6D8F6BC857C906 NO_PUBKEY 8B48AD6246925553
W: Failed to fetch
http://deb.debian.org/debian/dists/stretch-updates/InRelease  The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 7638D0442B90D010
W: Failed to fetch http://deb.debian.org/debian/dists/stretch/Release.gpg
 The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
NO_PUBKEY EF0F382A1A7B6500
W: Some index files failed to download. They have been ignored, or old ones
used instead.

Re: How Buster release may affect Unstable?

[Curt]

On 2019-07-01, Joe  wrote:
>
> Debian's main selling point is that a Stable can *always* be upgraded
> in place to the next version, so that kind of incompatibility does not

Then it will fail to live up to the marketing for the brave 600 or so
Debian users (according to Popularity Contest) regularly employing
ecryptfs-utils:

 The ecryptfs-utils package is not part of buster due to an unfixed
 serious bug (#765854). At the time of writing this paragraph, there was
 no clear advice for users of eCryptfs, except not to upgrade.

And yet the serious unfixed bug doesn't appear to even belong to
ecryptfs-utils per se, but rather to systemd:

 https://github.com/systemd/systemd/issues/8598
 systemd-user doesn't properly close its PAM session #8598

 The systemd --user instance that is started when a user first logs in (if
 pam_systemd is enabled) starts a subprocess "(sd-pam)" that opens a PAM session
 for the user, using the "systemd-user" service name. See setup_pam() in
 src/core/execute.c.

 However, this PAM session is not properly closed. 

Which results, in my understanding of the thing, in a Private directory
not being unmounted at user logout (ecryptfs-umount-private believing
one session is still remaining) and "bug" #765854.

Re: IPv4 v IPv6

[andreimpopescu]

On Lu, 17 iun 19, 10:05:11, mick crane wrote:
> hello,
> I know nothing about IPv6.

Then you don't have any prejudices ;) (no, IPv6 doesn't break your 
network).

> Can somebody point to a good explanation ?
> Without knowing anything about it I'm wondering if I should request an IPv6
> range from my ISP to use locally.

If it's free (cost) and you have the time to set it up properly.

> A network card have IPv4 and IPv6 addresses that are different, not the same
> address in different notation ?
> Then with firewalling do you need to specify both IPv4 and IPv6 ranges ?

Yes, as others have pointed out.

What I didn't see mentioned in this thread is that IPv6 does not 
need/use NAT. Some users rely on NAT in IPv4 as some sort of protection 
(it is not, you still need a firewall).

When properly configured[1] with IPv6 all devices on your home network 
supporting it will be directly accessible from the internet (by design).

Your firewall rules may need to be adjusted to account for this.

[1] depending on your ISP and/or modem you might not need to do anything 
at all with most recent OSes in their default configuration.

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


signature.asc
Description: PGP signature

Re: Document removal of ecryptfs-utils from Buster

[Gene Heskett]

On Monday 01 July 2019 19:42:08 David Wright wrote:

> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> > On Monday 01 July 2019 09:33:35 David Wright wrote:
> > > On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > > > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > > > > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > > > > >At this point, I'd call it a buster delaying bug.  That last
> > > > > > is going to cost too many that can't ignore it and don't
> > > > > > have unencrypted backups. Thats going to be a lot of very
> > > > > > bad PR.
> > > > >
> > > > > It's the release teams call, generally speaking, and one of
> > > > > the things they might factor in is the size of the user-base
> > > > > for the troublesome package. I'm surprised to find that it's
> > > > > extremely small according to popcon data: less than 1% of
> > > > > reporters:
> > > > > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> > > > >
> > > > > Compare just two alternatives:
> > > > >
> > > > > encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> > > > > cryptsetup: 15%
> > > > > https://qa.debian.org/popcon.php?package=cryptsetup
> > > >
> > > > That does put a better light on it.  From the comments so far, I
> > > > was thinking I'm one of the few not using it. I've depended on
> > > > dd-wrt between me and the internet for the last 16 years, and
> > > > even before that I was on dialup and the dialup folks didn't
> > > > have enough bandwidth to attract the black hats, so I've never
> > > > been touched.
> > >
> > > I was under the impression that these two forms of security,
> > > firewalls and encryption, are completely orthogonal. Once you've
> > > unlocked, say, an encrypted partition, you're now reliant on the
> > > firewall to keep strangers out of your files. OTOH a perfect
> > > firewall is of no benefit when your laptop is stolen.
> > >
> > > > With all the publicity this thread has given the issue, I'll
> > > > change my mind (as if it matters to the team :) and say adequate
> > > > notice and mitigating paths seems to have been given. Those that
> > > > are using it I'd call pretty advanced and are reading this list
> > > > just for the notices given so they shouldn't be surprised. So
> > > > I'll do an Andy Capp and shuddup.
> > >
> > > The grey area is for me is the relative benefit of encrypting file
> > > by file compared with the whole partition. Assuming that there's
> > > just one passphrase involved in each scenario, is more protection
> > > given by the former method? After all, once a partition is
> > > unlocked, all users on the system are able to read all the files,
> > > subject to the normal unix permissions, ACLs, etc.
> >
> > Whole filesystem encryption would be a total non-starter for me.
>
> Fair enough. Could you reveal why, or are your reasons cryptic too?

No, but if for some reason, say a cerebral accident, I should lose the 
password, the whole system would be locked away, and that would be 
unforgivable.  And at 84&counting, I've no warranty I'll remember my own 
name 10 minutes from my hitting send on this message.

> > File by
> > file with different passwd's according to whats in the file would
> > make far more sense to me. Thats my $0.02.
>
> I can't see how anyone would cope with a scheme like that. How would
> you remember all those passwords?

By limiting it to probably 2.  Normal stuff might just be my user pw, 
whereas stuff that is truly private might have a 2048 bit hash.
>
> OTOH I can see that each file must have an individual encryption key,
> but the encryption scheme looks after generating those. Otherwise
> you would have a large sample of encrypted but known-cleartext files
> available for cracking attempts. (Remember that the filenames are not
> encrypted, and many files on a system will have entirely predictable
> contents, eg much of /usr, your Debian package cache, and so on.

Clearly I haven't explored all the ramifications. Its been more of a case 
of letting my imagination out to play without a chaperone.

> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: An Ounce of Prevention

[andreimpopescu]

On Lu, 17 iun 19, 14:20:33, Bob Bernstein wrote:
> For a change, I want to proceed with a tad of caution 
> rather than follow Don't RTFM - Wing That Sucker.
> 
> I have an old Jessie running:
> 
> Linux debian.localdomain 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) 
> x86_64 GNU/Linux
> 
> ...and it has been borne in on me that my kernel needs to 
> be retired. This old Jessie dates back to the Bad Old Days 
> of the systemd wars and has no systemd onboard. I am of a 
> mood though to take a Great Leap Forward and install 
> Stretch -- systemd 'n all.

Just for the archives, upgrading to stretch (or buster) does not 
necessarily involve switching to systemd.

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


signature.asc
Description: PGP signature

Re: How Buster release may affect Unstable?

[Dave Sherohman]

On Mon, Jul 01, 2019 at 03:34:55PM -0400, Default User wrote:
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  Or something like
> systemd infects the distribution or its rate of metastasis accelerates,
> etc.  Or an important package management system or communication protocol
> is superseded or falls into disuse, or is simply abandoned by its
> developers or maintainers.
> 
> I was wondering if an existing Unstable setup could diverge so far from
> Stable that major surgery would be necessary, or even complete replacement
> with Stable, followed by conversion to contemporaneous Unstable.

I think the core misunderstanding here is that you seem to be assuming
that, when a new stable comes out, a new unstable is created to go with
it.

This is not the case.  *NOTHING* ever goes from stable into unstable.
*EVERYTHING* in stable[1] got there by way of unstable (with a stop off
in testing along the way).  If a major change happens in stable, then it
already happened some months or years ago in unstable:

- New filesystems start in unstable, then move to stable.

- systemd for Debian was first implemented in unstable, then made its
  way into stable.

- If apt were to somehow be replaced, that process would happen in
  unstable and the new package management tools would first appear
  there, before migrating into stable.

So, no, a new stable release would never break unstable.  Any breakage
that may happen would be flowing in the other direction (something
coming from unstable breaks stable), and even that is extremely rare.


[1] ...except security updates, which have their own path into stable
that doesn't pass through unstable, but they're not going to be
introducing major changes anyhow.

-- 
Dave Sherohman

Re: Debian Perl or Brew Perl for production application?

[Dave Sherohman]

On Mon, Jul 01, 2019 at 06:30:19PM +0200, to...@tuxteam.de wrote:
> I tend to stick to Debian packages as my primary choice, resorting
> to off-distribution packages when needed (e.g. not packaged for
> Debian, or I /need/ a newer version). Of course it takes some foresight
> to guess in advance whether you expect such a situation in the
> future.
> 
> Rationale: they mesh better with the flow of system updates/upgrades.
> 
> I've found Perl packaging in Debian outstanding. The Debian Perl
> packaging team does a damn good job indeed.

Pretty much the same here.  I was initially hired as a Perl developer,
then gradually moved into more sysadmin duties and, in both roles, I
prefer to stick with the Debian-packaged perl binary.  It gets me
security updates as needed and the only reasons I see a particular need
for PerlBrew and the like are:

1) You need different compile-time options than Debian chooses

2) You need access to a feature that's only present in a newer-than-
   Debian Perl version

3) You want to have the "latest and greatest" for its own sake

Personally, I've never encountered #1 or #2 in practice and if #3
mattered to me, then I wouldn't be running Debian stable in the first
place.

-- 
Dave Sherohman

Re: Choice of VMs under i386 Stretch?

[Richard Owlett]

On 07/01/2019 01:43 PM, Linux-Fan wrote:

Richard Owlett writes:

[...]


I do not understand.


It was an attempt to give you a list of packages that may allow you to 
start using VMs without further checks ...




That your answer was "a list of packages" is key to the communication 
problem.


A restatement of my question might be:

I run the i386 version of Debian 9.8.
Using only contents of that set of installation DVDs, I wish to use a VM 
host capable of running multiple VM guests. Although the guests will be 
running in command line mode, the host should have a GUI.

What choice metapackages provide that function?

Re: Debian Perl or Brew Perl for production application?

[Alex Mestiashvili]

On 7/2/19 11:20 AM, Dave Sherohman wrote:
> On Mon, Jul 01, 2019 at 06:30:19PM +0200, to...@tuxteam.de wrote:
>> I tend to stick to Debian packages as my primary choice, resorting
>> to off-distribution packages when needed (e.g. not packaged for
>> Debian, or I /need/ a newer version). Of course it takes some foresight
>> to guess in advance whether you expect such a situation in the
>> future.
>>
>> Rationale: they mesh better with the flow of system updates/upgrades.
>>
>> I've found Perl packaging in Debian outstanding. The Debian Perl
>> packaging team does a damn good job indeed.
> 
> Pretty much the same here.  I was initially hired as a Perl developer,
> then gradually moved into more sysadmin duties and, in both roles, I
> prefer to stick with the Debian-packaged perl binary.  It gets me
> security updates as needed and the only reasons I see a particular need
> for PerlBrew and the like are:
> 
> 1) You need different compile-time options than Debian chooses
> 
> 2) You need access to a feature that's only present in a newer-than-
>Debian Perl version
> 
> 3) You want to have the "latest and greatest" for its own sake
> 
> Personally, I've never encountered #1 or #2 in practice and if #3
> mattered to me, then I wouldn't be running Debian stable in the first
> place.
> 

+1 here, but in case one need the "latest and greatest" modules, in most
cases it's dead simple to package a not-yet-packaged module with
cpan2deb from dh-make-perl package.

One of the benefits of this approach, is that you don't need to bring
compilers and sources of the dependencies to the production machine.
Build packages on a "development" node and install binary packages on
the production.

In case you need to replicate the setup, or you have more than one
machine one can maintain a repository,making installation of a new
system way easier.

And you also can contribute back to Debian in case you packaged a new
software.

Best,
Alex

70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[The Wanderer]

On 2019-07-01 at 03:47, Curt wrote:

> Another, less serious, gotcha for those inveterate upgraders and
> newbies who don't read the release notes is that 
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid 
> mechanism for defining device names. This mechanism (automagically) 
> permitted users upgrading from Wheezy to Stretch (where the
> old-style names were deprecated) to continue using their obsolete,
> legacy interface names (eth0, anyone?).
> 
> Me, I migrated to the new-fangled denominations as per the
> instructions at the link below to obviate the eventual loss of
> network connectivity, which is a bummer when you don't what you're
> doing and all the help available is at the other end of the severed
> wire.
> 
> https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

(Any particular reason you linked to the s390x version of the release
notes? It seems to match e.g. the amd64 one for this purpose, so it
shouldn't make a difference, it's just a little unexpected.)

I'm skeptical as to whether this is (still/currently) accurate.

After reading the conversation in the ensuing subthread about cases
where the old-style names as defined in that file were still picked up
and used without troubles after a buster upgrade, I went looking for
more information.

/usr/share/doc/udev/README.Debian.gz has a section on the subject of
migration from the old naming scheme to the new one. Although it does
not seem to state as much explicitly, from that section (and other parts
of the file related to interface names), it appears as if this detail
may apply only to machines running systemd. In particular, the file's
multiple references to /etc/systemd/network/99-default.link seem as if
they may be relevant.

Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces' found
a reference to bug 919390, which seems to be about someone reporting
this behavior as a bug. That bug has been closed as "fixed upstream",
and that closure is what I found in the changelog. The patch which fixes
the bug was committed as being a revert of an earlier change. That
commit happened in January, and the package was released to unstable on
January 27th; it's long since made it to testing, i.e., buster.

It's still possible that there's other activity which affects all of
this and which I've missed (related to the non-udev systemd packages,
most likely), but at a glance, it looks as if the release notes and the
README alike may be inaccurate / out of date. Even if they aren't, it
looks as if they may be incomplete, by describing only the situation as
it affects machines with systemd.


Although I don't run systemd on this machine, and my second system which
used to have it (and I think still does) doesn't use it as the init
system, I manage a very minor server at work which does use it as init
system. In the event that we actually upgrade that server rather than
migrating its service to another machine, this change may wind up being
relevant to me; I'll want to keep it in mind.

-- 
   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: Choice of VMs under i386 Stretch?

[Curt]

On 2019-07-02, Richard Owlett  wrote:
>
> A restatement of my question might be:
>
> I run the i386 version of Debian 9.8.
> Using only contents of that set of installation DVDs, I wish to use a VM 
> host capable of running multiple VM guests. Although the guests will be 
> running in command line mode, the host should have a GUI.
> What choice metapackages provide that function?

What do we win if we provide the correct answer? A year's supply of
invective?

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Curt]

On 2019-07-02, The Wanderer  wrote:

>> https://www.debian.org/releases///buster/s390x/release-notes/ch-informa=
> tion.en.html#migrate-interface-names
>
> (Any particular reason you linked to the s390x version of the release
> notes? It seems to match e.g. the amd64 one for this purpose, so it
> shouldn't make a difference, it's just a little unexpected.)

I screwed up and didn't realize, but that guy in Philly running Debian
on an IBM mainframe feels less left out maybe.

> I'm skeptical as to whether this is (still/currently) accurate.

Me too, after speaking briefly over the wire with Greg Wooledge.

> After reading the conversation in the ensuing subthread about cases
> where the old-style names as defined in that file were still picked up
> and used without troubles after a buster upgrade, I went looking for
> more information.

That's the spirit.

> /usr/share/doc/udev/README.Debian.gz has a section on the subject of
> migration from the old naming scheme to the new one. Although it does
> not seem to state as much explicitly, from that section (and other parts
> of the file related to interface names), it appears as if this detail
> may apply only to machines running systemd. In particular, the file's
> multiple references to /etc/systemd/network/99-default.link seem as if
> they may be relevant.

Well, in the bug thread 919390 referenced below Martin Pitt does say

 We believe that the bug you reported is fixed in the latest version of
 systemd, which is due to be installed in the Debian FTP archive.

"in the latest version of systemd."

> Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces' found
> a reference to bug 919390, which seems to be about someone reporting
> this behavior as a bug. That bug has been closed as "fixed upstream",
> and that closure is what I found in the changelog. The patch which fixes
> the bug was committed as being a revert of an earlier change. That
> commit happened in January, and the package was released to unstable on
> January 27th; it's long since made it to testing, i.e., buster.

That appears to be correct from a rapid perusal of the referenced
bug.

> It's still possible that there's other activity which affects all of
> this and which I've missed (related to the non-udev systemd packages,
> most likely), but at a glance, it looks as if the release notes and the
> README alike may be inaccurate / out of date. Even if they aren't, it
> looks as if they may be incomplete, by describing only the situation as
> it affects machines with systemd.

Not even that, it seems (no longer affects systemd).

> Although I don't run systemd on this machine, and my second system which
> used to have it (and I think still does) doesn't use it as the init
> system, I manage a very minor server at work which does use it as init
> system. In the event that we actually upgrade that server rather than
> migrating its service to another machine, this change may wind up being
> relevant to me; I'll want to keep it in mind.

I was going to upgrade to Buster a couple of weeks ahead of time, taking
the bull by the horns for once rather than procrastinating, which is my
ultimate tendency in life, and began reading the release notes (for the
wrong architecture, but, come on, nobody's perfect). It never crossed my
mind to doubt the accuracy of those notes until yesterday when Greg
piped up. 

Maybe we should file a bug report against the release notes.

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

[andreimpopescu]

On Mi, 19 iun 19, 11:06:59, Bagas Sanjaya wrote:
> Hello all Debian Users,
> 
> Consider the hypothetical scenario below.

Your hypothetical scenario is not relevant for what you are asking.

Context for the list:
https://lists.debian.org/debian-devel/2019/06/msg00371.html
 
> I often encountered cases on systems in television stations when they
> configured sudoers like this snippet below:
> 
> %remaja ALL=(ALL:ALL) ALL
> 
> The rationale for above is most programs on such systems can only be
> accessed by users which are member of remaja (teens) group via sudo, so
> their sysadmins giving remaja user group full administrator privileges. Is
> it dangerous?

Knives are dangerous when used improperly, but we still have them at 
home.

Instead of locking them away we teach children to use them safely.

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


signature.asc
Description: PGP signature

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[The Wanderer]

On 2019-07-02 at 08:37, Curt wrote:

> On 2019-07-02, The Wanderer  wrote:

>> /usr/share/doc/udev/README.Debian.gz has a section on the subject
>> of migration from the old naming scheme to the new one. Although it
>> does not seem to state as much explicitly, from that section (and
>> other parts of the file related to interface names), it appears as
>> if this detail may apply only to machines running systemd. In
>> particular, the file's multiple references to
>> /etc/systemd/network/99-default.link seem as if they may be
>> relevant.
> 
> Well, in the bug thread 919390 referenced below Martin Pitt does say
> 
> We believe that the bug you reported is fixed in the latest version
> of systemd, which is due to be installed in the Debian FTP archive.
> 
> "in the latest version of systemd."

That's an artifact of the fact that udev is maintained as part of the
systemd source package, because it's maintained upstream as part of the
systemd project. If my understanding is correct, committing a change to
the Debian udev package means committing a change to the systemd package
collection's changelog.

I consider that maintenance situation to have unfortunate negative
consequences, and this is one of them, albeit one of the more minor
examples.

>> Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces'
>> found a reference to bug 919390, which seems to be about someone
>> reporting this behavior as a bug. That bug has been closed as
>> "fixed upstream", and that closure is what I found in the
>> changelog. The patch which fixes the bug was committed as being a
>> revert of an earlier change. That commit happened in January, and
>> the package was released to unstable on January 27th; it's long
>> since made it to testing, i.e., buster.
> 
> That appears to be correct from a rapid perusal of the referenced 
> bug.
> 
>> It's still possible that there's other activity which affects all
>> of this and which I've missed (related to the non-udev systemd
>> packages, most likely), but at a glance, it looks as if the release
>> notes and the README alike may be inaccurate / out of date. Even if
>> they aren't, it looks as if they may be incomplete, by describing
>> only the situation as it affects machines with systemd.
> 
> Not even that, it seems (no longer affects systemd).

Have you confirmed that? It seems possible that on a systemd machine,
things in other packages (such as whatever would provide that
99-default.link file, which unfortunately - because it's under /etc/ -
can't be easily found through 'apt-file search') might still be
overriding 70-persistent-net.rules, even with this change reverted.

>> Although I don't run systemd on this machine, and my second system
>> which used to have it (and I think still does) doesn't use it as
>> the init system, I manage a very minor server at work which does
>> use it as init system. In the event that we actually upgrade that
>> server rather than migrating its service to another machine, this
>> change may wind up being relevant to me; I'll want to keep it in
>> mind.
> 
> I was going to upgrade to Buster a couple of weeks ahead of time,
> taking the bull by the horns for once rather than procrastinating,
> which is my ultimate tendency in life, and began reading the release
> notes (for the wrong architecture, but, come on, nobody's perfect).
> It never crossed my mind to doubt the accuracy of those notes until
> yesterday when Greg piped up.
> 
> Maybe we should file a bug report against the release notes.

If we can confirm that the behavior described is inaccurate (i.e., that
70-persistent-net.rules still works, even on a latest-buster machine
running full-on systemd), then yes, I think that would be definitely best.

We're a bit late for it, given that the release is scheduled for the
coming Friday or Saturday (I forget which), but at least reporting it
couldn't hurt. (Assuming there isn't a report about it already; I
haven't checked.)

-- 
   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: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 4:30 AM, Richard Owlett wrote:

> A restatement of my question might be:
> 
> I run the i386 version of Debian 9.8.
> Using only contents of that set of installation DVDs, I wish to use a VM
> host capable of running multiple VM guests. Although the guests will be
> running in command line mode, the host should have a GUI.
> What choice metapackages provide that function?

You have your answer already in previous emails.

The Wiki provides a list of software capable of turning Debian into a VM
host [1]. They include full hardware virtualization such as Qemu,
containers such as Docker, and pseudo-virtualization such as Schroot.
Its up to you to determine which one best suits your needs, as all of
these VM host programs can do what you want.

1:
https://wiki.debian.org/SystemVirtualization#Using_Debian_to_host_Virtual_Computers

To determine *which* installation DVD contains one of these programs,
you will need to look at the individual wiki page for each VM host
program, see which package or packages you need, and check the DVD .list
files to see which DVD contains that package [2]. You should also be
aware that each package may have untold number of dependencies, so I
suggest you look at each individual package [3], figure out the
dependencies, and then figure out which dvd those dependencies are on.

2: https://cdimage.debian.org/cdimage/release/current/i386/list-dvd/
3: https://packages.debian.org/

Is this a lot of work? Yes.

Normally I would recommend VirtualBox for its ease of use, but
Virtualbox is *not* found on the installation DVDs.

Depending on your hardware, native virtualization might not even be
possible. I suggest consulting your CPU manufacturer to determine if it
is. If you are using an Intel CPU, you can visit their product page to
see if it supports VT-x [4]. I can't speak for AMD CPUs or other brand
CPUs, though it should be revealed in the output of lscpu

4: https://ark.intel.com

If native virtualization is not available, you may be required to use a
container or a pseudo-virtualization option.

-Matt



signature.asc
Description: OpenPGP digital signature

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Greg Wooledge]

On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> On 2019-07-02 at 08:37, Curt wrote:
> > Not even that, it seems (no longer affects systemd).
> 
> Have you confirmed that?

I'm using systemd, and the 70-* file was used when I upgraded to buster,
but that was roughly 2 months ago.  I haven't tested on current buster.

> It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /etc/ -
> can't be easily found through 'apt-file search') might still be
> overriding 70-persistent-net.rules, even with this change reverted.

wooledg:~$ locate 99-default
/lib/systemd/network/99-default.link

wooledg:~$ dpkg -S 99-default
udev: /lib/systemd/network/99-default.link

wooledg:~$ cat /lib/systemd/network/99-default.link 
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 6:04 AM, Matthew Crews wrote:

> To determine *which* installation DVD contains one of these programs,
> you will need to look at the individual wiki page for each VM host
> program, see which package or packages you need, and check the DVD .list
> files to see which DVD contains that package [2]. You should also be
> aware that each package may have untold number of dependencies, so I
> suggest you look at each individual package [3], figure out the
> dependencies, and then figure out which dvd those dependencies are on.

Addendum:

An alternative method is to look at each individual package, figure out
which packages you need, download the .deb files for each package, put
them on removable media (CD-R/RW, DVD-R/RW, or a usb flash drive), put
the removable media in your host machine, and install from the removable
media.

On an internet-capable host, you can download the .deb for apps foo and
bar this way (without root access):

$ apt download foo bar

make sure you pay attention to the file name afterwards:

$ pwd
/path/to/file
$ ls *.deb
foo_3.14.deb  bar_2.18.deb

To install a .deb file, you can either use apt to point to the file:

$ sudo apt install /path/to/file/foo_3.14.deb /path/to/file/bar_2.18.deb

Or you can use dpkg:

$ sudo dpkg -i /path/to/file/foo_3.14.deb /path/to/file/bar_2.18.deb

-Matt



signature.asc
Description: OpenPGP digital signature

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[The Wanderer]

On 2019-07-02 at 09:10, Greg Wooledge wrote:

> On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> 
>> On 2019-07-02 at 08:37, Curt wrote:
>> 
>>> Not even that, it seems (no longer affects systemd).
>> 
>> Have you confirmed that?
> 
> I'm using systemd, and the 70-* file was used when I upgraded to
> buster, but that was roughly 2 months ago.  I haven't tested on
> current buster.

It would be worth trying, although I'm not currently in a position to
easily put together a testbed machine (or VM) for this purpose.

>> It seems possible that on a systemd machine, things in other
>> packages (such as whatever would provide that 99-default.link file,
>> which unfortunately - because it's under /etc/ - can't be easily
>> found through 'apt-file search') might still be overriding
>> 70-persistent-net.rules, even with this change reverted.
> 
> wooledg:~$ locate 99-default
> /lib/systemd/network/99-default.link
> 
> wooledg:~$ dpkg -S 99-default
> udev: /lib/systemd/network/99-default.link

Hmm. Apparently I didn't search for the right thing; I just used the
full explicit path, including /etc/, which found nothing.

I'm guessing this is a case where the systemd pattern of having config
files under /lib/ and symlinking them from under /etc/ is in use, and
that one of /etc/systemd, /etc/systemd/network/, and
/etc/systemd/network/99-default.link is a symlink.

/etc/systemd/network/ doesn't appear on my system, but 99-default.link
does exist under /lib, with the same contents as you gave from yours.

-- 
   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: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Curt]

On 2019-07-02, The Wanderer  wrote:

>> Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that? It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /etc/ -
> can't be easily found through 'apt-file search') might still be
> overriding 70-persistent-net.rules, even with this change reverted.

https://github.com/systemd/systemd/issues/11436

https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
 
 Let's revert, and start with a clean slate. This fixes #11436.

(#11436 being 'network interface is renamed although NAME has been set by
udev rule'.)

Maybe I'm not understanding this (quite possible).

Somebody on an up-to-date Buster could perform Michael Biebl's bug
reproduction test:

 To reproduce the issue, create a file 
/etc/udev/rules.d/70-persistent-net.rules containing

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="", 
KERNEL=="eth*", NAME="lan0"

 with the mac address of your ethernet network interface.
 Unload the network module (in my case 8139cp), then load it again.
 Notice how the interface is properly renamed:

 [ 3750.870434] 8139cp :00:03.0 lan0: renamed from eth0
 Now run udevadm trigger --action=add

 [ 3752.509458] 8139cp :00:03.0 ens3: renamed from lan0
 The interface is renamed although a custom NAME has been set.

Sorry if this is noise.

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[The Wanderer]

On 2019-07-02 at 10:10, Curt wrote:

> On 2019-07-02, The Wanderer  wrote:
> 
>>> Not even that, it seems (no longer affects systemd).
>> 
>> Have you confirmed that? It seems possible that on a systemd
>> machine, things in other packages (such as whatever would provide
>> that 99-default.link file, which unfortunately - because it's under
>> /etc/ - can't be easily found through 'apt-file search') might
>> still be overriding 70-persistent-net.rules, even with this change
>> reverted.
> 
> https://github.com/systemd/systemd/issues/11436
> 
> https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
>  
>  Let's revert, and start with a clean slate. This fixes #11436.
> 
> (#11436 being 'network interface is renamed although NAME has been
> set by udev rule'.)

Yeah, I read that, although I didn't read #11436.

> Maybe I'm not understanding this (quite possible).

I think you're reading it the same way I am. I'm just questioning
whether what we're seeing here represents the whole picture, and partly
also whether this is the latest word on the subject.

It might be interesting to know when that section of the release notes
was last modified, relative to when this change was made.

> Somebody on an up-to-date Buster could perform Michael Biebl's bug 
> reproduction test:

In particular, someone on a machine running full-on systemd. My
available machines are either non-systemd or not systemd-as-init, so my
observed results aren't applicable.

-- 
   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: Choice of VMs under i386 Stretch?

[Kenneth Parker]

On Tue, Jul 2, 2019, 8:05 AM Curt  wrote:

> On 2019-07-02, Richard Owlett  wrote:
> >
> > A restatement of my question might be:
> >
> > I run the i386 version of Debian 9.8.
> > Using only contents of that set of installation DVDs, I wish to use a VM
> > host capable of running multiple VM guests. Although the guests will be
> > running in command line mode, the host should have a GUI.
> > What choice metapackages provide that function?
>

I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?

>
> What do we win if we provide the correct answer? A year's supply of

invective?
>

An Invection Oven?:-D

Kenneth Parker

Re: Choice of VMs under i386 Stretch?

[Greg Wooledge]

On Tue, Jul 02, 2019 at 11:17:06AM -0400, Kenneth Parker wrote:
> I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?

No, because it isn't free software.

See  for details.

Re: Choice of VMs under i386 Stretch?

[Stefan Monnier]

>> I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?
> No, because it isn't free software.
> See  for details.

I believe what you wrote is slightly misleading: the base VirtualBox
software seems to satisfy the definition of Free Software just fine.
The above wiki page mentions two problems for Debian packaging:
- There's a proprietary "add-on" for it, but that doesn't affect the
  status of the base system. 
- There's a lack of interest from the main developers to provide
  long-term support for older releases which made it too much trouble
  for Debian's security team to provide support for it, so it's not in
  Debian any more.


Stefan

Re: gnupg / enigmail excessive processing times

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 24/6/19 12:14 am, The Wanderer wrote:
> The short version of this is that I think I need to clear out a
> lot of irrelevant keys / signatures, et cetera, from my gnupg 
> configuration - but I don't want to do anything which risks losing 
> my private key(s), or any related information.

Your problem is most likely polluted keys due to a major design flaw
with SKS serverv.

I've seen two keys become extremely large due to junk being added and
the behaviour of anything using my public keyring was horribly slow
and with the CPU pinning by one process.

The following has been sent to a couple of local LUGs that I'm in:

For those of us whom use OpenPGP/GPG keys with GNUPG implementation
(perhaps everyone whom interacts with SKS servers)... there has been a
very long standing technical problem that is currently causing issues.

The problem, in a nutshell causes keys to significantly increase in
size due to bad data being easily uploaded to the SKS servers without
proper validation and consequently severely effecting performance of
anything using the public keyring database.  If you experience the
problem, it will be due to a significant increase of the size of your
public keyring file.  When processing the public keyring data, the CPU
gets pinned at 100% for at least one thread.

What I have done is a full export of keys to ASCII armoured files and
look at the larger files -- in my case the two largest were for Micah
Lee and the Tor Project keys.  Delete problematic keys and import
fresh sane data for them.

Having older backups of the Tor Project's key, I've replaced the key
with one that doesn't have the extra bad payload.  The former key
/may/ not be easily found as the Tor website directs you to an SKS
server to collect the data and it doesn't appear to be easily
available directly from Tor project's own website.

For Micah Lee's key, I got it from keybase.io (micahflee).
   https://keybase.io/micahflee

There are different solutions, keybase.io is but one.  In any case the
SKS servers are in big trouble as they stand today.

A reason for the problem popping up might be related to a simple key
refresh; so that is a major problem.  It's been said that even just
using the keys can cause problems when you don't have any keys with
bad data, but I'm not so sure about that.


And a follow up:


Without any specific refresh, my Tor Project key grew again.

I've change my gpg.conf now, let's see if that stops the problem.

Using an alternate server:


keyserver hkp://keys.openpgp.org


More details here:
https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/

Cheers
A.
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXRuDNwAKCRCoFmvLt+/i
+zbSAP0Zh8WrQMJaEQRegRl+rBoNCucSSwySGAa4Iy/CbRr+GAD9G4FOYnJMs363
98asLeJ3TGuBWgjEqLVUItNH9HIOblE=
=uA5x
-END PGP SIGNATURE-

Re: How Buster release may affect Unstable?

[Default User]

On Tue, Jul 2, 2019, 05:38 Dave Sherohman  wrote:

> On Mon, Jul 01, 2019 at 03:34:55PM -0400, Default User wrote:
> > What if a new Stable release introduces a major change to the existing
> > distribution technology or methodology?
> >
> > For example, a new default filesystem is introduced.  Or something like
> > systemd infects the distribution or its rate of metastasis accelerates,
> > etc.  Or an important package management system or communication protocol
> > is superseded or falls into disuse, or is simply abandoned by its
> > developers or maintainers.
> >
> > I was wondering if an existing Unstable setup could diverge so far from
> > Stable that major surgery would be necessary, or even complete
> replacement
> > with Stable, followed by conversion to contemporaneous Unstable.
>
> I think the core misunderstanding here is that you seem to be assuming
> that, when a new stable comes out, a new unstable is created to go with
> it.
>
> This is not the case.  *NOTHING* ever goes from stable into unstable.
> *EVERYTHING* in stable[1] got there by way of unstable (with a stop off
> in testing along the way).  If a major change happens in stable, then it
> already happened some months or years ago in unstable:
>
> - New filesystems start in unstable, then move to stable.
>
> - systemd for Debian was first implemented in unstable, then made its
>   way into stable.
>
> - If apt were to somehow be replaced, that process would happen in
>   unstable and the new package management tools would first appear
>   there, before migrating into stable.
>
> So, no, a new stable release would never break unstable.  Any breakage
> that may happen would be flowing in the other direction (something
> coming from unstable breaks stable), and even that is extremely rare.
>
>
> [1] ...except security updates, which have their own path into stable
> that doesn't pass through unstable, but they're not going to be
> introducing major changes anyhow.
>
> --
> Dave Sherohman
>




Okay.

This is pretty much what I was thinking, and is as expected.

Thank you to those who gave helpful, constructive replies.

Re: gnupg / enigmail excessive processing times

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

> On 24/6/19 12:14 am, The Wanderer wrote:
>> The short version of this is that I think I need to clear out a
>> lot of irrelevant keys / signatures, et cetera, from my gnupg
>> configuration - but I don't want to do anything which risks losing
>> my private key(s), or any related information.
> 
> Your problem is most likely polluted keys due to a major design flaw
> with SKS serverv.

This looks interesting too, but unfortunately there are major
problems, performance is, but one, of the major problems.

https://daniel-lange.com/archives/159-Cleaning-a-broken-GNUpg-gpg-key.ht
ml

Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXRuMkQAKCRCoFmvLt+/i
+02QAQCnB0lAGSsUqjqiFDYhG4RKnng+5xmz5/Hrhm3frVOsWwEAhohuitUo88gI
MayoIpBEB0G+4faq+Ehw3QtcOhy5GWY=
=YZbA
-END PGP SIGNATURE-

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 8:34 AM, Stefan Monnier wrote:
>>> I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?
>> No, because it isn't free software.
>> See  for details.
>
> I believe what you wrote is slightly misleading: the base VirtualBox
> software seems to satisfy the definition of Free Software just fine.
> The above wiki page mentions two problems for Debian packaging:
> - There's a proprietary "add-on" for it, but that doesn't affect the
>   status of the base system.

Technically Debian places Virtualbox in Contrib since version 4.2
because a non-free component is required to build the BIOS.

> - There's a lack of interest from the main developers to provide
>   long-term support for older releases which made it too much trouble
>   for Debian's security team to provide support for it, so it's not in
>   Debian any more.

This is the primary driver as to why Stretch places Virtualbox in
backports, and why Buster will not have Virtualbox packages in the
Debian repo at all.

Additionally, Oracle no longer supports i386 versions of Virtualbox, not
since version 6.0.0.

For that reason I would not recommend using Virtualbox unless you are
intending to use the Oracle-supplied packages, and I certainly would not
recommend using the i386 versions.

-Matt





signature.asc
Description: OpenPGP digital signature

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 8:34 AM, Stefan Monnier wrote:
>>> I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?
>> No, because it isn't free software.
>> See  for details.
>
> I believe what you wrote is slightly misleading: the base VirtualBox
> software seems to satisfy the definition of Free Software just fine.
> The above wiki page mentions two problems for Debian packaging:
> - There's a proprietary "add-on" for it, but that doesn't affect the
>   status of the base system.

Technically Debian places Virtualbox in Contrib since version 4.2
because a non-free component is required to build the BIOS.

> - There's a lack of interest from the main developers to provide
>   long-term support for older releases which made it too much trouble
>   for Debian's security team to provide support for it, so it's not in
>   Debian any more.

This is the primary driver as to why Stretch places Virtualbox in
backports, and why Buster will not have Virtualbox packages in the
Debian repo at all.

Additionally, Oracle no longer supports i386 versions of Virtualbox, not
since version 6.0.0.

For that reason I would not recommend using Virtualbox unless you are
intending to use the Oracle-supplied packages, and I certainly would not
recommend using the i386 versions.

-Matt





signature.asc
Description: OpenPGP digital signature

Re: How Buster release may affect Unstable?

[Curt]

On 2019-07-02, Curt  wrote:
> On 2019-07-01, Joe  wrote:
>>
>> Debian's main selling point is that a Stable can *always* be upgraded
>> in place to the next version, so that kind of incompatibility does not
>
> Then it will fail to live up to the marketing for the brave 600 or so
  1066

Oops. One thousand and sixty-six regular users of ecryptfs-utils. We are
legion. It's 'encfs' with only 600 or so regular users (622, to be exact).

> Debian users (according to Popularity Contest) regularly employing
> ecryptfs-utils:

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 8:34 AM, Stefan Monnier wrote:
>>> I'm partial to VirtualBox.   Is that on any of the Debian DVD'S?
>> No, because it isn't free software.
>> See  for details.
> 
> I believe what you wrote is slightly misleading: the base VirtualBox
> software seems to satisfy the definition of Free Software just fine.
> The above wiki page mentions two problems for Debian packaging:
> - There's a proprietary "add-on" for it, but that doesn't affect the
>   status of the base system. 

Technically Debian places Virtualbox in Contrib since version 4.2
because a non-free component is required to build the BIOS.

> - There's a lack of interest from the main developers to provide
>   long-term support for older releases which made it too much trouble
>   for Debian's security team to provide support for it, so it's not in
>   Debian any more.

This is the primary driver as to why Stretch places Virtualbox in
backports, and why Buster will not have Virtualbox packages in the
Debian repo at all.

Additionally, Oracle no longer supports i386 versions of Virtualbox, not
since version 6.0.0.

For that reason I would not recommend using Virtualbox unless you are
intending to use the Oracle-supplied packages, and I certainly would not
recommend using the i386 versions.

-Matt



signature.asc
Description: OpenPGP digital signature

Re: how to use systemd to delete old files and directories on stretch?

[D. R. Evans]

Sven Joachim wrote on 6/28/19 11:06 PM:

> 
> If you cannot get systemd-tmpfiles-clean.service to do its job,
> something like this should do the trick:
> 
> find /tmp -mindepth 1 -mtime +35 -atime +35 -delete
> 

I was hoping to avoid having to write a script (because obviously one needs to
add some protective code around that basic invocation of find), but I guess
I'll have to do so, since it seems clear from your explanation that the
systemd folk use "age" in a way that means something quite different than its
plain and ordinary meaning. That's pretty much what I'd decided anyway, but I
was hoping that I was missing some simple systemd command that actually works
on age, not on something else.

Thanks for the reply and the explanation.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Brian]

On Tue 02 Jul 2019 at 10:22:56 -0400, The Wanderer wrote:

> On 2019-07-02 at 10:10, Curt wrote:
> 
> > On 2019-07-02, The Wanderer  wrote:
> > 
> >>> Not even that, it seems (no longer affects systemd).
> >> 
> >> Have you confirmed that? It seems possible that on a systemd
> >> machine, things in other packages (such as whatever would provide
> >> that 99-default.link file, which unfortunately - because it's under
> >> /etc/ - can't be easily found through 'apt-file search') might
> >> still be overriding 70-persistent-net.rules, even with this change
> >> reverted.
> > 
> > https://github.com/systemd/systemd/issues/11436
> > 
> > https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
> >  
> >  Let's revert, and start with a clean slate. This fixes #11436.
> > 
> > (#11436 being 'network interface is renamed although NAME has been
> > set by udev rule'.)
> 
> Yeah, I read that, although I didn't read #11436.
> 
> > Maybe I'm not understanding this (quite possible).
> 
> I think you're reading it the same way I am. I'm just questioning
> whether what we're seeing here represents the whole picture, and partly
> also whether this is the latest word on the subject.
> 
> It might be interesting to know when that section of the release notes
> was last modified, relative to when this change was made.

Not long after 6th April 2019:

  https://lists.debian.org/debian-doc/2019/04/msg00012.html


> > Somebody on an up-to-date Buster could perform Michael Biebl's bug 
> > reproduction test:
> 
> In particular, someone on a machine running full-on systemd. My
> available machines are either non-systemd or not systemd-as-init, so my
> observed results aren't applicable.

My upgrade from stretch to buster left networking as it was before. My
70-persistent-net.rules is

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:90:dc:a2:4d:26",
 ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Following Curt's suggestion I removed the relevant module and rebooted.
'ip a' shows eth0. The advice in the Release Notes

 > 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.

does not accord with my experience. In the light of #919390 it seems
doubtful to me that the "Migrating from legacy network interface names"
section is useful.

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

Re: Choice of VMs under i386 Stretch?

[Andy Smith]

Hello Curt and Matthew,

On Tue, Jul 02, 2019 at 12:04:36PM -, Curt wrote:
> On 2019-07-02, Richard Owlett  wrote:
> >
> > A restatement of my question might be:

[…]

> What do we win if we provide the correct answer? A year's supply of
> invective?

I do feel sorry for you Matthew. You have been enticed into spending
considerable time giving a thorough answer in an Owlett thread.
Unfortunately Owlett threads are either an ongoing Internet
performance art project or a result of severe mental illness (why
not both!?), not sincere requests for help.

Now, which one of you is going to tell him that running virtual
machines is a bit of a stretch on a 32-bit host?

Better luck next time! :)

Cheers,
Andy

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

Re: Choice of VMs under i386 Stretch?

[Linux-Fan]

Richard Owlett writes:


On 07/01/2019 01:43 PM, Linux-Fan wrote:

Richard Owlett writes:

[...]


I do not understand.


It was an attempt to give you a list of packages that may allow you to start
using VMs without further checks ...


That your answer was "a list of packages" is key to the communication
problem.

A restatement of my question might be:

I run the i386 version of Debian 9.8.
Using only contents of that set of installation DVDs, I wish to use a VM
host capable of running multiple VM guests. Although the guests will be
running in command line mode, the host should have a GUI.
What choice metapackages provide that function?


Thank you very much for the rephrasing -- the use of `host` and `guest`
aids the description very well.

TL;DR: There is (AFAICT) no metapackage satisfying your requirements.

* * *

The long version:

As far as I can tell, there is no Debian metapackage to install my preferred
virt-manager (GUI) + libvirt (backend) + KVM (hypervisor) setup:

$ apt rdepends virt-manager
virt-manager
Reverse Depends:
  Depends: mdvl-virtualization

$ aptitude show mdvl-virtualization
Package: mdvl-virtualization
Version: 1.0.0
New: yes
State: installed
Automatically installed: yes
Priority: optional
Section: admin
Maintainer: Linux-Fan 
Architecture: all
Uncompressed Size: 0
Depends: virt-manager, qemu, qemu-kvm, libvirt-clients, libvirt0, 
libvirt-daemon,
 libvirt-daemon-system
Description: MDVL Virtualization efforts
 This metapackage installs common virtualization technology for MDVL, 
i.e. KVM and frontend.

For my local purposes, I have created my own metapackage (not in Debian...)
-- this is why I suggested a list of packages: I expect that installing all
of the packages yields the same result (except for automatically vs.
manually installed packages...) as if a metapackage were used. In case it is
of use to you, I can send you an e-mail with a copy of my metapackage
(it is about 4 KiB as per `du -sh`, but it does not do well for world-wide
publication because it is not Debian Policy compliant etc. thus not
uploaded/attached anywhere yet).

HTH
Linux-Fan


pgpgBLFXwZZ9u.pgp
Description: PGP signature

Re: Output from apt-get update.

[peter]

From: Matthew Crews 
Date: Wed, 12 Jun 2019 06:00:26 +0200 (CEST)
> What does your "/etc/apt/sources.list" file look like on your two machines?

Here they are.

# imager:/etc/apt/sources.list
# Security updates
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
# mirror.it.ubc.ca = 137.82.116.42
deb http://137.82.116.42/debian stretch main contrib non-free
deb-src http://137.82.116.42/debian stretch main contrib non-free
# stretch-updates, previously known as 'volatile'
deb http://137.82.116.42/debian stretch-updates main contrib non-free
deb-src http://137.82.116.42/debian stretch-updates main contrib non-free
# stretch backports
deb http://137.82.116.42/debian stretch-backports main contrib non-free
deb-src http://137.82.116.42/debian stretch-backports main contrib non-free

# dalton:/etc/apt/sources.list
# Security updates
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
# mirror.it.ubc.ca = 137.82.116.42
deb http://137.82.116.42/debian stretch main contrib non-free
deb-src http://137.82.116.42/debian stretch main contrib non-free
# debian.oregonstate.edu = 140.211.166.134
#deb http://140.211.166.141/debian jessie main contrib non-free
#deb-src http://140.211.166.141/debian jessie main contrib non-free
# Stable updates
deb http://137.82.116.42/debian stretch-updates main contrib non-free
deb-src http://137.82.116.42/debian stretch-updates main contrib non-free
# Stable backports
deb http://137.82.116.42/debian stretch-backports main contrib non-free
deb-src http://137.82.116.42/debian stretch-backports main contrib non-free

As I see, sources.list from the two systems are identical, except for comments.

> Its unusual to directly point to an IP address for the Debian repos, as
> opposed to point to the domain name.

dalton has dnsmasq.  From distant recollection, name resolution failed when 
the system was running and dnsmasq was not.  That motivated direct reference 
to IP addresses.  To the best of my knowledge, an IP address should suffice to 
identify a server or possibly a cluster of them. 

I don't understand the intent or meaning of the hypothetical long path cited 
repeatedly.  Eg.
root@imager:/home/peter# apt-get update
Get:1 file:/full/path/to/build/packaging/deb ./ InRelease
Ign:1 file:/full/path/to/build/packaging/deb ./ InRelease
Get:2 file:/full/path/to/build/packaging/deb ./ Release
Ign:2 file:/full/path/to/build/packaging/deb ./ Release
Get:3 file:/full/path/to/build/packaging/deb ./ Packages
Ign:3 file:/full/path/to/build/packaging/deb ./ Packages
Get:4 file:/full/path/to/build/packaging/deb ./ Translation-en_US
Ign:4 file:/full/path/to/build/packaging/deb ./ Translation-en_US
  ...

Whereas dalton just confirms the sources.list
root@dalton:/home/peter# apt-get update
Ign:1 http://137.82.116.42/debian stretch InRelease
Hit:2 http://137.82.116.42/debian stretch-updates InRelease
Hit:3 http://137.82.116.42/debian stretch-backports InRelease
Hit:4 http://137.82.116.42/debian stretch Release
Hit:5 http://security.debian.org stretch/updates InRelease
Reading package lists... Done
root@dalton:/home/peter# 

Any ideas about that?  Incidentally, what is "Ign"?

Thanks,... P.



-- 
https://en.wikibooks.org/wiki/Oberon
Tel: +1 604 670 0140Bcc: peter at easthope. ca

ncurses?

[ghe]

Buster, Supermicro 5036T (aka sbox), Radeon HD 6450/7450/8450 according
to lspci, RME Hammerfall sound card

I asked for help with this a few days ago and attached a screenshot to
show what my problem is. There've been no replies -- I guess graphics
are caught by a spam filter somewhere.

The problem is that, on sbox, alsamixer and aptitude are badly displayed
-- alsamixer so bad that it's not usable. The vertical lines in
alsamixer are broken into pieces and the pieces are offset a quarter of
an inch or so. The horizontals aren't broken, but their positions are
offset like the vertical pieces. Some of them.

I can't use my sound card without alsamixer. Aptitude's problems are
just a nuisance that I expect to see fixed RSN.

I hope that's enough to explain what's going on. If not, please say so,
and I'll put the screenshot on my website.

lynx is fine. And there are no difficulties with GUI stuff.

When I run one of these programs and 'ps aux' I see lynx or alsamixer or
aptitude, but no ncurses. I'm not sure what, if anything, that means.
But I expected to see ncurses.

The problem on sbox is fairly new. I don't know which update broke it
because I don't need the sound card very often. It worked since the
early alsa days and I didn't change anything, I promise.

Both problem programs are fine on the Dell laptop (also running Buster)
in the next room. When I SSH to the laptop and run alsamixer over there,
it's better on my screen, but not right. When I run alsamixer on sbox,
SSH to the laptop, and SSH back to sbox, it's unintelligible again on
the sbox screen.

I can't find anything remotely like this on the web.

At first I guessed something was wrong in Linux' Radeon driver. But I'm
not so sure anymore because lynx has no problems. But lynx doesn't try
to make pictures, and text is fine everywhere...

At a loss. Ideas?

-- 
Glenn English

Re: ncurses?

[Jude DaShiell]

Try running script if the system is already installed then run each of
the problem commands then type exit.  You'll get a file called
typescript which is ansi text that probably will get through the spam
filters if you include it in the body of your message and do not attach
it.  If the ansi can be cleaned out of typescript the reading will be
cleaner and the file a little shorter.

On Tue, 2 Jul 2019, ghe wrote:

> Date: Tue, 2 Jul 2019 19:45:32
> From: ghe 
> To: debian-user 
> Subject: ncurses?
> Resent-Date: Tue,  2 Jul 2019 23:45:49 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> Buster, Supermicro 5036T (aka sbox), Radeon HD 6450/7450/8450 according
> to lspci, RME Hammerfall sound card
>
> I asked for help with this a few days ago and attached a screenshot to
> show what my problem is. There've been no replies -- I guess graphics
> are caught by a spam filter somewhere.
>
> The problem is that, on sbox, alsamixer and aptitude are badly displayed
> -- alsamixer so bad that it's not usable. The vertical lines in
> alsamixer are broken into pieces and the pieces are offset a quarter of
> an inch or so. The horizontals aren't broken, but their positions are
> offset like the vertical pieces. Some of them.
>
> I can't use my sound card without alsamixer. Aptitude's problems are
> just a nuisance that I expect to see fixed RSN.
>
> I hope that's enough to explain what's going on. If not, please say so,
> and I'll put the screenshot on my website.
>
> lynx is fine. And there are no difficulties with GUI stuff.
>
> When I run one of these programs and 'ps aux' I see lynx or alsamixer or
> aptitude, but no ncurses. I'm not sure what, if anything, that means.
> But I expected to see ncurses.
>
> The problem on sbox is fairly new. I don't know which update broke it
> because I don't need the sound card very often. It worked since the
> early alsa days and I didn't change anything, I promise.
>
> Both problem programs are fine on the Dell laptop (also running Buster)
> in the next room. When I SSH to the laptop and run alsamixer over there,
> it's better on my screen, but not right. When I run alsamixer on sbox,
> SSH to the laptop, and SSH back to sbox, it's unintelligible again on
> the sbox screen.
>
> I can't find anything remotely like this on the web.
>
> At first I guessed something was wrong in Linux' Radeon driver. But I'm
> not so sure anymore because lynx has no problems. But lynx doesn't try
> to make pictures, and text is fine everywhere...
>
> At a loss. Ideas?
>
>

-- 

Hey. wie geht’s?

[Oliver Dr . Muth]

Lass dir das nicht entgehen! https://laullansunli1973.blogspot.cl/






___
Gruß
Oliver Dr. Muth

Re: Output from apt-get update.

[peter]

From: Francisco M Neto 
Date: Wed, 12 Jun 2019 07:27:28 -0300
> It's also worth checking if there's anything under
> /etc/apt/sources.list.d/

peter@dalton:/etc/apt$ ls /etc/apt/sources.list.d/*
ls: cannot access '/etc/apt/sources.list.d/*': No such file or directory
peter@dalton:/etc/apt$

peter@imager:~$ ls /etc/apt/sources.list.d/*
/etc/apt/sources.list.d/mythtv.list
peter@imager:~$

With any luck, mythtv.list isn't involved in this conundrum.

The mainboard interface appears as eth0.
"ip link show" reports eth0 is up.
"ip addr show" reports an IPv6 address for eth0.  No IPv4 address.

ping to a neighbour reports 
  connect: network is unreachable
  
Is IPv6 the default now?  Shorewall configuration needs updating?

Online documentation still has numerous mentions of ifconfig.
https://wiki.debian.org/NetworkConfiguration is a prime example.

Here and there a remark that ip is the new tool replacing ifconfig and 
etc.  Difficult for a non-expert to decide when to use and old command 
and when a shiney new one.   8~(

Any further ideas?

Thanks,... P.



-- 
https://en.wikibooks.org/wiki/Oberon
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Geoff]

The Wanderer wrote:

On 2019-07-02 at 10:10, Curt wrote:


On 2019-07-02, The Wanderer  wrote:


Not even that, it seems (no longer affects systemd).


Have you confirmed that? It seems possible that on a systemd
machine, things in other packages (such as whatever would provide
that 99-default.link file, which unfortunately - because it's under
/etc/ - can't be easily found through 'apt-file search') might
still be overriding 70-persistent-net.rules, even with this change
reverted.


https://github.com/systemd/systemd/issues/11436

https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
  
  Let's revert, and start with a clean slate. This fixes #11436.


(#11436 being 'network interface is renamed although NAME has been
set by udev rule'.)


Yeah, I read that, although I didn't read #11436.


Maybe I'm not understanding this (quite possible).


I think you're reading it the same way I am. I'm just questioning
whether what we're seeing here represents the whole picture, and partly
also whether this is the latest word on the subject.

It might be interesting to know when that section of the release notes
was last modified, relative to when this change was made.


Somebody on an up-to-date Buster could perform Michael Biebl's bug
reproduction test:


In particular, someone on a machine running full-on systemd. My
available machines are either non-systemd or not systemd-as-init, so my
observed results aren't applicable.



I'm running up to date sid and using systemd and still have an eth0 as set by 
70-persistent-net.rules.

Geoff

Re: Output from apt-get update.

[Matthew Crews]

On 7/2/19 5:18 PM, pe...@easthope.ca wrote:
> From: Francisco M Neto 
> Date: Wed, 12 Jun 2019 07:27:28 -0300
>> It's also worth checking if there's anything under
>> /etc/apt/sources.list.d/
> peter@imager:~$ ls /etc/apt/sources.list.d/*
> /etc/apt/sources.list.d/mythtv.list
> peter@imager:~$
> 
> With any luck, mythtv.list isn't involved in this conundrum.

Something tells me that it is worth a look. What are the contents of
/etc/apt/sources.list.d/mythtv.list ?

-Matt



signature.asc
Description: OpenPGP digital signature

Re: ncurses?

[Felix Miata]

ghe composed on 2019-07-02 17:45 (UTC-0600):

https://lists.debian.org/debian-user/2019/07/msg00110.html

It's been eons since I heard of any kind of trouble with ncurses. :-) sbox I'm 
not
familiar with. :-(

I have a Dell gfxcard on a Buster test box that may be the same as yours except
for the brand. Perhaps you'd see improvement by swapping the radeon DDX for the
default DDX (modesetting) as I use here.

I don't usually try to make sound work, or even connect speakers, on my test
boxes, but alsamixer does open seemingly ready to take orders:

http://fm.no-ip.com/SS/Deb/alsamixer10m.png

Simplest way for you to switch DDX should be to purge xserver-xorg-video-radeon.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Correct: Re: Output from apt-get update.

[peter]

From: Francisco M Neto 
Date: Wed, 12 Jun 2019 07:27:28 -0300
> It's also worth checking if there's anything under
> /etc/apt/sources.list.d/

You're right.  If /etc/apt/sources.list.d/mythtv.list is disabled, 
apt-get update doesn't produce obscure complaints.  The complaints 
from apt-get could help by identifying the bad repository.

A D-link card gives a network connection.  The mainboard NIC alone is 
problematic.  ??

So the system working again, more or less.  I'm still wondering about 
IPv4 vs. IPv6 and ip vs. other stuff.

Thanks for the help,  ... P.


-- 
https://en.wikibooks.org/wiki/Oberon
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/2/19 1:20 PM, Andy Smith wrote:
> I do feel sorry for you Matthew. You have been enticed into spending
> considerable time giving a thorough answer in an Owlett thread.
> Unfortunately Owlett threads are either an ongoing Internet
> performance art project or a result of severe mental illness (why
> not both!?), not sincere requests for help.

I have an innate desire to help people, but more importantly I give
people the benefit of the doubt. Besides I self-taught myself a few
things along the way, so I consider it a win.

I have no idea what an Owlett thread is, other than it sounds like a
Pokémon or one of the characters from the cartoon PJ Masks. Or is it
just another name for good old fashioned trolling?

> Now, which one of you is going to tell him that running virtual
> machines is a bit of a stretch on a 32-bit host?
> 
> Better luck next time! :)

I'm not going to discount that someone has a perfectly good reason for
wanting to do this, even if it is for academic purposes. Granted, I
think in this day and age it is a bit silly to try and run a VM on a
32-bit host (or for that matter, run a 32-bit host at all if your
hardware supports 64-bit, but that is another topic).

That said I do not believe that any existing i386 32-bit-only hardware
that is still floating around even supports the virtual machine
extensions necessary to run a true VM host. Containers like Docker?
Sure, those should still work, but I'm not an expert in the subject.

-Matt



signature.asc
Description: OpenPGP digital signature

Re: ncurses?

[andreimpopescu]

On Ma, 02 iul 19, 17:45:32, ghe wrote:
> Buster, Supermicro 5036T (aka sbox), Radeon HD 6450/7450/8450 according
> to lspci, RME Hammerfall sound card
 
[...]
 
> The problem is that, on sbox, alsamixer and aptitude are badly displayed

Apparently "sbox" is the host name (or how you refer to it). It would be 
useful to be explicit about this, to avoid confusions.

> -- alsamixer so bad that it's not usable. The vertical lines in
> alsamixer are broken into pieces and the pieces are offset a quarter of
> an inch or so. The horizontals aren't broken, but their positions are
> offset like the vertical pieces. Some of them.

Is this in an terminal window under X or on the console?
Is "regular" shell output fine otherwise (e.g. 'ls -l') in xterms and/or 
console?

My first recommendation is to make sure your locale and console is 
properly configured.

dpkg-reconfigure locales
dpkg-reconfigure console-setup

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


signature.asc
Description: PGP signature

Re: Choice of VMs under i386 Stretch?

[tomas]

On Wed, Jul 03, 2019 at 05:01:11AM +0200, Matthew Crews wrote:
> On 7/2/19 1:20 PM, Andy Smith wrote:
> > I do feel sorry for you Matthew. You have been enticed into spending
> > considerable time giving a thorough answer in an Owlett thread.
> > Unfortunately Owlett threads are either an ongoing Internet
> > performance art project or a result of severe mental illness (why
> > not both!?), not sincere requests for help.

While this may soundsomewhat funny, it is pretty unfriendly: you
never know how cranky others might find *you* -- so better hope
for some slack in your favour :-)

> I have an innate desire to help people, but more importantly I give
> people the benefit of the doubt. Besides I self-taught myself a few
> things along the way, so I consider it a win.

I prefer that one, too :)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Setting up bind9/DNS

[Alessandro Vesely]

On Fri 28/Jun/2019 22:02:52 +0200 Joe wrote:
> On Fri, 28 Jun 2019 11:44:54 -0500 Dennis Wicks  wrote:
> 
>> I was thinking that I could setup a nameserver on my machine 
>> with enries in it for the virtual hosts and have my local 
>> network address in the list of nameservers in my 
>> modem/router, and that is where I need the help.
> 
> There are probably simpler solutions, but BIND works fine.

yep!

> The thing you need to know is 'rpz', Response Policy Zone. Otherwise
> you would have to set up a separate zone file for each of your domains.
> With rpz, you can just throw any hostname and IP address into one file,
> a sort of /etc/hosts for BIND.

Oh, well, RPZ is certainly a nice addon, but I wouldn't call it a 
simplification.

Actually, BIND doesn't need a file for each host.  It needs a file for each
zone, which is what is called a /zone file/.  So long as all virtual hosts
share the same TLD, they fit on the same zone file.

Bind allows different views.  That feature allows you to use internal network
number and names on the internal view only, in case you use the server also to
maintain a public domain name.

And of course, you can configure ISC DHCP to work with it.


Good luck
Ale
--