Re: Debian 11, Chrome and .asp pages

[tomas]

On Sat, Aug 27, 2022 at 07:10:52PM -0400, Greg Wooledge wrote:
> On Sat, Aug 27, 2022 at 07:05:46PM -0400, Timothy M Butterworth wrote:
> > On Sat, Aug 27, 2022 at 6:48 PM Greg Wooledge  wrote:
> > 
> > > On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > > > Yes, no problems accessing the .asp pages with Debian 10 and chrome.
> > > Both
> > > > 10 and 11 have the latest Chrome version.
> > >
> > > Wait, wait, wait, wait.
> > >
> > > I am *so* confused right now.  Is the Debian system the WEB SERVER, or
> > > is it the WEB BROWSER
> > >
> > 
> > The Debian system is the web browser, a SOHO router is the server.
> 
> So the problem is *not* "I have a .asp site and my web server stopped
> serving it properly", but rather "my browser is trying to hit a URL
> that happens to end with .asp and it's not working".
> 
> Then all the focus on the 4 characters .asp in the URL are a complete
> red herring.

Thanks, that was my point. I just couldn't express it so concisely :)

> What's the actual *symptom*?  What does the web browser say or do when
> hitting this URL?

Perhaps the 404 is coming in response to a subordinate resource (e.g.
the Location: in a redirect or some other of the 3129 ways the Web
has to play that game). That resource would depend on "the browser"
in some general sense.

Oh wait: does have the new installation a different /etc/hosts?
Perhaps the OP has made an entry "back then" to get the router's
cra^H^H^H Very Special GUI working? Something like that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian 11, Chrome and .asp pages

[tomas]

On Sat, Aug 27, 2022 at 06:47:46PM -0400, Greg Wooledge wrote:
> On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > Yes, no problems accessing the .asp pages with Debian 10 and chrome.  Both
> > 10 and 11 have the latest Chrome version.
> 
> Wait, wait, wait, wait.
> 
> I am *so* confused right now.  Is the Debian system the WEB SERVER, or
> is it the WEB BROWSER?

AFAIU the web browser.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian 11, Chrome and .asp pages

[tomas]

On Sun, Aug 28, 2022 at 12:09:51AM +0200, Ángel wrote:
> On 2022-08-27 at 20:32 +0200, to...@tuxteam.de wrote:
> > On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > > Yes, no problems accessing the .asp pages with Debian 10 and
> > > chrome.  Both 10 and 11 have the latest Chrome version.  I'm not
> > > seeing any version change notes for Chrome or Debian 11 that appear
> > > to affect this .asp behavior.  Not to say I haven't missed
> > > something.
> > 
> > Hm. As I said -- the .asp shouldn't be the problem. I don't know
> > Chrome very well (I try to avoid it), so I fear I can't help. Perhaps
> > there is a debugging mode to see exactly what request is receiving
> > the 404 answer. Then compare with the functioning version.
> > 
> > A 404 is definitely server-side (unless Chrome is lying to you).
> > 
> > Cheers
> 
> In Chromium you can use Ctrl+Shit+I to open the developer tools, where
> you have a Network tab where requests and responses can be seen.
> 
> Tony, as Tomas noted, the error will be provided by the router itself,
> not the browser. The router might be doing something strange, such as
> returning different responses based on the User Agent, or it loses
> track that the user is logged in, and in that case it shows a 404...

...or it generates a link to some local (the user's computer) resource
(which then would exist in the old installation but not in the new) or
something like that. Web is like that. It's dystopia let loose ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: at wits end

[David Wright]

On Tue 23 Aug 2022 at 20:36:39 (+0100), Brian wrote:
> On Tue 23 Aug 2022 at 10:19:04 -0500, David Wright wrote:
> 
> > FF's ability to print has improved a lot recently. Not perfect, mind.
> 
> Perhaps you would expand on this? Previous drawbacks?

The main problem was overlong pages, which would overprint the
headers/footers, and sometimes lead to missing material in the
page breaks.

Also odd font sizes, so large that headings occluded the main text,
or so small as to be difficult to read yet squeezing the text into
a narrow column.

Occasionally, printing all the main text on (an overflowing) page one,
but continuing the marginal text down the sides of subsequent (but
otherwise blank) pages.

> Improvements?

The biggest improvement came, IIRC, with the introduction of that
Print overlay panel that has the pageable preview on the left and
the controls on the right. (Previously, selecting Print would only
display a little progress bar/percentage as it printed.)

Cheers,
David.

Re: Debian 11, Chrome and .asp pages

[Greg Wooledge]

On Sat, Aug 27, 2022 at 07:05:46PM -0400, Timothy M Butterworth wrote:
> On Sat, Aug 27, 2022 at 6:48 PM Greg Wooledge  wrote:
> 
> > On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > > Yes, no problems accessing the .asp pages with Debian 10 and chrome.
> > Both
> > > 10 and 11 have the latest Chrome version.
> >
> > Wait, wait, wait, wait.
> >
> > I am *so* confused right now.  Is the Debian system the WEB SERVER, or
> > is it the WEB BROWSER
> >
> 
> The Debian system is the web browser, a SOHO router is the server.

So the problem is *not* "I have a .asp site and my web server stopped
serving it properly", but rather "my browser is trying to hit a URL
that happens to end with .asp and it's not working".

Then all the focus on the 4 characters .asp in the URL are a complete
red herring.

What's the actual *symptom*?  What does the web browser say or do when
hitting this URL?

Re: Debian 11, Chrome and .asp pages

[Timothy M Butterworth]

On Sat, Aug 27, 2022 at 6:48 PM Greg Wooledge  wrote:

> On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > Yes, no problems accessing the .asp pages with Debian 10 and chrome.
> Both
> > 10 and 11 have the latest Chrome version.
>
> Wait, wait, wait, wait.
>
> I am *so* confused right now.  Is the Debian system the WEB SERVER, or
> is it the WEB BROWSER
>

The Debian system is the web browser, a SOHO router is the server.

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

Re: Debian 11, Chrome and .asp pages

[Greg Wooledge]

On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> Yes, no problems accessing the .asp pages with Debian 10 and chrome.  Both
> 10 and 11 have the latest Chrome version.

Wait, wait, wait, wait.

I am *so* confused right now.  Is the Debian system the WEB SERVER, or
is it the WEB BROWSER?

Re: Debian 11, Chrome and .asp pages

[Ángel]

On 2022-08-27 at 20:32 +0200, to...@tuxteam.de wrote:
> On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> > Yes, no problems accessing the .asp pages with Debian 10 and
> > chrome.  Both 10 and 11 have the latest Chrome version.  I'm not
> > seeing any version change notes for Chrome or Debian 11 that appear
> > to affect this .asp behavior.  Not to say I haven't missed
> > something.
> 
> Hm. As I said -- the .asp shouldn't be the problem. I don't know
> Chrome very well (I try to avoid it), so I fear I can't help. Perhaps
> there is a debugging mode to see exactly what request is receiving
> the 404 answer. Then compare with the functioning version.
> 
> A 404 is definitely server-side (unless Chrome is lying to you).
> 
> Cheers

In Chromium you can use Ctrl+Shit+I to open the developer tools, where
you have a Network tab where requests and responses can be seen.

Tony, as Tomas noted, the error will be provided by the router itself,
not the browser. The router might be doing something strange, such as
returning different responses based on the User Agent, or it loses
track that the user is logged in, and in that case it shows a 404...

Regards

Re: Debian 11, Chrome and .asp pages

[tony mollica]

Yes, no problems accessing the .asp pages with Debian 10 and chrome.  Both 10 
and 11 have the latest Chrome version.  I'm not seeing any version change notes 
for Chrome or Debian 11 that appear to affect this .asp behavior.  Not to say I 
haven't missed something.


TM

On 8/27/22 12:16, to...@tuxteam.de wrote:

On Sat, Aug 27, 2022 at 10:53:18AM -0600, tony mollica wrote:

Understood.

But it works with Debian 10 and not with Debian 11, so my main question is
'what changed?'


Does it /still/ work with Debian 10, though?

Cheers

Re: probably silly Question

[gene heskett]

On 8/27/22 12:21, Stefan Monnier wrote:

What sort of hoops would I have to take a running swan dive thru to
have cura, on this machine, directly drive /sshnet/rock64/dev/ttyACM0,
my Prusa MK3S+ printer? I'm already logged into it over my local net
twice and it would sure save me a lot of sneakernetting to get
a design from OpenSCAD, thru cura to slice it ad into printed PETG+CF
on its build plate.

You might be able to get this working using `socat` or maybe `ser2net`,
but I don't know enough about such printers to be sure.
I suspect that the possible timing issues introduced by a network
connection might be problematic.  I suspect that the command that
actively drives the ttyACM0 device will be happier if it can live on
your rock64 machine.


I mean what good is all this networking if it can't be used?

Usually I do things like `ssh  printcmd` to save myself from having
to go through that kind of healthy physical exercise.


 Stefan
Thanks Stefan.   I think I've got octoprint working again. But its 
obviously not a multiple
printer friendly since the output port it will use is not in the printer 
profile, but in main.
I've got 2 rock64's, but not a monitor/keyboard/mouse switcher. So I 
could setup a 2nd
rock64 if I had room for the extra keyboard, monitor and mouse. Or a kvm 
switch.


I'm closer to having the ender5plus working as the printrun kit's 
pronsole, which doesn't
need the gui, connects to and has configured the Ender5plus now, so now 
I need to
make a bass ackwards prox switch act like a BLTouch. So if I setup a 2nd 
rock64 with octoprint,
and get the bed leveling working on the Ender5plus, I'll be in hog 
heaven. Then I can use

mc to copy cura's output to the correct rock64 for an automatic print.

So I'm off to find a kvm switch.

Take care and stay well,

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Debian 11, Chrome and .asp pages

[tomas]

On Sat, Aug 27, 2022 at 12:28:38PM -0600, tony mollica wrote:
> Yes, no problems accessing the .asp pages with Debian 10 and chrome.  Both
> 10 and 11 have the latest Chrome version.  I'm not seeing any version change
> notes for Chrome or Debian 11 that appear to affect this .asp behavior.  Not
> to say I haven't missed something.

Hm. As I said -- the .asp shouldn't be the problem. I don't know Chrome very
well (I try to avoid it), so I fear I can't help. Perhaps there is a debugging
mode to see exactly what request is receiving the 404 answer. Then compare
with the functioning version.

A 404 is definitely server-side (unless Chrome is lying to you).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian 11, Chrome and .asp pages

[tomas]

On Sat, Aug 27, 2022 at 10:53:18AM -0600, tony mollica wrote:
> Understood.
> 
> But it works with Debian 10 and not with Debian 11, so my main question is
> 'what changed?'

Does it /still/ work with Debian 10, though?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian 11, Chrome and .asp pages

[tony mollica]

Understood.

But it works with Debian 10 and not with Debian 11, so my main question is 'what 
changed?'


TM

On 8/26/22 12:53, to...@tuxteam.de wrote:

On Fri, Aug 26, 2022 at 11:37:41AM -0600, tony mollica wrote:

Good morning (Mountain time).

Here's the problem I'm having.  Debian is so stable that issues I've
resolved years ago took place so far back and with no issues that I forget
how I did it. So it is with this latest issue.  The problem is I need to log
into a router and make some changes, preferably using my Linux laptop.  I
can log in but several of the configuration pages are in the .asp format and
my Chrome or Firefox browsers running on a fresh Debian 11 install won't
display the pages and gives me a 404 error.  What is my Debian install
missing to allow my to access these pages.  There's no problem using
Debian10, only 11 and also no issues using the 'other' OS.


Hm. .asp is a server-side thing (i.e. the server transforms whatever into
html and serves it). It's Microsoft's version of CGI, back from last century.

The 404 is also a server-side thing (i.e. at the router side). Your Linux
laptop isn't involved in that, it's just reporting what it "sees".

Thus, can't be at the root of the 404. You'll have to describe in more detail
what is going on.

That might take some back-and-forth.

Cheers

Re: Weird set -u error

[David]

On Sun, 28 Aug 2022 at 01:30, Greg Wooledge  wrote:
> On Sun, Aug 28, 2022 at 12:46:17AM +1000, David wrote:

> > I think there might be one remaining aspect still mysterious, so there
> > might be yet another factor beyond the FIVE you identified ...
> >
> > The fact that this statement, first shown by Tim, does NOT error:
> >
> >   $ ( bash -uc : ; : )
>
> (inside an ssh session)
>
> This is related to how bash optimizes subshell commands when it can.
>
> unicorn:~$ (bash -uc :)
> /etc/bash.bashrc: line 7: PS1: unbound variable
> unicorn:~$ (bash -uc : ; :)
> unicorn:~$
>
> In the first one, there's just one command inside the subshell, so bash
> can replace one of the fork() calls, and treat it like
>
> (exec bash -uc :)
>
> In the second one, there's a second command, so bash can't perform that
> same optimization.
>
> (exec bash -uc : ; :)   would not work the same as   (bash -uc : ; :)
>
> This optimization affects whether the shell_level is reset:
>
> unicorn:~$ (bash -c 'declare -p SHLVL')
> declare -x SHLVL="1"
> unicorn:~$ (bash -c 'declare -p SHLVL'; :)
> declare -x SHLVL="2"
>
> Under normal conditions, this would have no visible effect.  But because
> of the other factors involved, we can see a difference.

Thanks. Is SHLVL something that is useful to understand?
Is there any documentation about it apart from reading the source?
'man bash' is extremely terse about it. But bash exposes it to users,
so I wonder why, what is it useful for?

Re: Weird set -u error

[Greg Wooledge]

On Sun, Aug 28, 2022 at 12:46:17AM +1000, David wrote:
> I think there might be one remaining aspect still mysterious, so there
> might be yet another factor beyond the FIVE you identified ...
> 
> The fact that this statement, first shown by Tim, does NOT error:
> 
>   $ ( bash -uc : ; : )

(inside an ssh session)

This is related to how bash optimizes subshell commands when it can.

unicorn:~$ (bash -uc :)
/etc/bash.bashrc: line 7: PS1: unbound variable
unicorn:~$ (bash -uc : ; :)
unicorn:~$ 

In the first one, there's just one command inside the subshell, so bash
can replace one of the fork() calls, and treat it like

(exec bash -uc :)

In the second one, there's a second command, so bash can't perform that
same optimization.

(exec bash -uc : ; :)   would not work the same as   (bash -uc : ; :)

This optimization affects whether the shell_level is reset:

unicorn:~$ (bash -c 'declare -p SHLVL')
declare -x SHLVL="1"
unicorn:~$ (bash -c 'declare -p SHLVL'; :)
declare -x SHLVL="2"

Under normal conditions, this would have no visible effect.  But because
of the other factors involved, we can see a difference.

Re: Weird set -u error

[David]

On Sun, 28 Aug 2022 at 00:17, Greg Wooledge  wrote:
> On Sat, Aug 27, 2022 at 09:52:11AM -0400, Greg Wooledge wrote:

> > I also can't explain this (still inside the ssh localhost session):
> >
> > unicorn:~$ (bash -c 'declare -p PS1')
> > declare -- PS1="\\h:\\w\\\$ "
> > unicorn:~$ (bash -cu 'declare -p PS1')
> > /etc/bash.bashrc: line 7: PS1: unbound variable
> > /etc/bash.bashrc: line 1: declare: PS1: not found
> >
> > Why would adding the -u option change whether PS1 gets unset?  Not a clue.
>
> It turns out, this is a bit of an illusion.  It's not -u causing PS1 to
> be unset.  bash -c unsets PS1 (because it's launching a non-interactive
> shell) -- but since it's inside an ssh session and has shell_level < 2,
> it *also* reads the startup files.
>
> In the first example above, reading the startup files succeeds, because
> there is no -u.
>
> In the second example above, reading the startup files fails, because
> of -u.  Thus, PS1 remains unset.  The part of the startup files that
> would have set PS1 never gets executed.
>
> I believe all of the behaviors have been explained now.

Thanks for sharing your explanation, that's quite an impressive
investigation. My C skills are pretty minimal so I would have no hope to to
figure any of that out. Although I can follow the syntax at the statement
level and have occasionally written or patched some useful C code myself,
I struggle to comprehend other people's real-world C at any higher level.

I think there might be one remaining aspect still mysterious, so there
might be yet another factor beyond the FIVE you identified ...

The fact that this statement, first shown by Tim, does NOT error:

  $ ( bash -uc : ; : )

[david@kablamm ~]$ ssh kablamm
Linux kablamm 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
Last login: Sat Aug 27 17:02:53 2022 from 10.1.1.2
[david@kablamm ~]$ ( bash -cu : )
/etc/bash.bashrc: line 7: PS1: unbound variable
[david@kablamm ~]$ ( bash -cu : ; : )
[david@kablamm ~]$

Re: Weird set -u error

[Greg Wooledge]

On Sat, Aug 27, 2022 at 09:52:11AM -0400, Greg Wooledge wrote:
> I also can't explain this (still inside the ssh localhost session):
> 
> 
> unicorn:~$ (bash -c 'declare -p PS1')
> declare -- PS1="\\h:\\w\\\$ "
> unicorn:~$ (bash -cu 'declare -p PS1')
> /etc/bash.bashrc: line 7: PS1: unbound variable
> /etc/bash.bashrc: line 1: declare: PS1: not found
> 
> 
> Why would adding the -u option change whether PS1 gets unset?  Not a clue.

It turns out, this is a bit of an illusion.  It's not -u causing PS1 to
be unset.  bash -c unsets PS1 (because it's launching a non-interactive
shell) -- but since it's inside an ssh session and has shell_level < 2,
it *also* reads the startup files.

In the first example above, reading the startup files succeeds, because
there is no -u.

In the second example above, reading the startup files fails, because
of -u.  Thus, PS1 remains unset.  The part of the startup files that
would have set PS1 never gets executed.

I believe all of the behaviors have been explained now.

Re: networking.service: start operation timed out

[Greg Wooledge]

On Sat, Aug 27, 2022 at 09:07:49PM +0800, Jeremy Ardley wrote:
> Further to my longer reply on this list, there are three separate network
> configuration & management services that can be running at the same time on
> a debian system
> 
>  * networking.service
>  * systemd-networkd.service
>  * NetworkManager.service
> 
> The usual mode of operation under systemd has
> 
>  * networking.service always enabled
>  * NetworkManager.service is usually enabled by default
>  * systemd-networkd.service may or may not be enabled by default, but
>usually has no meaningful configuration
> 
> My experience is to leave networking.service handling loopback and then have
> either systemd-networkd.service to manage the more complex stuff, or have
> NetworkManager.service do this.

For the record, NetworkManager.service is typically only installed if
you select a Desktop Environment (GNOME, KDE, etc.).  On a system without
one of those beasts installed:

unicorn:~$ systemctl status NetworkManager.service
Unit NetworkManager.service could not be found.

In which case, network interface configuration is probably handled
exclusively by networking.service (a.k.a. /etc/network/interfaces).

None of these configurations is "right" or "wrong".  All that matters
is getting one of them to work for you.  If you prefer NM, then by all
means use NM -- even if you have to install it separately.  If you
prefer interfaces(5), then use that.

Re: Weird set -u error

[Greg Wooledge]

On Sat, Aug 27, 2022 at 05:12:57PM +1000, David wrote:
> I have modified my ssh environment so that it is not the default.
> But I do see a similar error message, using ssh from stable Debian 11.
> 
> [david@kablamm ~]$ ( bash -cu : )
> [david@kablamm ~]$ ssh kablamm
> Linux kablamm 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
> Last login: Sat Aug 27 17:00:13 2022 from 10.1.1.2
> [david@kablamm ~]$ ( bash -cu : )
> /etc/bash.bashrc: line 7: PS1: unbound variable
> [david@kablamm ~]$

Same here, with no special trickery.


unicorn:~$ (bash -cu :)
unicorn:~$ ssh localhost
greg@localhost's password: 
Linux unicorn 5.10.0-17-amd64 #1 SMP Debian 5.10.136-1 (2022-08-13) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Aug 16 07:35:44 2022
unicorn:~$ (bash -cu :)
/etc/bash.bashrc: line 7: PS1: unbound variable


So it's definitely coming from the Debian bash patch that triggeres the
special behavior when bash detects itself to be a child of ssh.  I've
got no clue (yet!) why it's only triggered using a subshell.

I also can't explain this (still inside the ssh localhost session):


unicorn:~$ (bash -c 'declare -p PS1')
declare -- PS1="\\h:\\w\\\$ "
unicorn:~$ (bash -cu 'declare -p PS1')
/etc/bash.bashrc: line 7: PS1: unbound variable
/etc/bash.bashrc: line 1: declare: PS1: not found


Why would adding the -u option change whether PS1 gets unset?  Not a clue.

Anyway, this is the segment of the upstream bash source (config-top.h)
where the compile-time ssh detection feature can be enabled:


/* Define this if you want bash to try to check whether it's being run by
   sshd and source the .bashrc if so (like the rshd behavior).  This checks
   for the presence of SSH_CLIENT or SSH2_CLIENT in the initial environment,
   which can be fooled under certain not-uncommon circumstances. */
/* #define SSH_SOURCE_BASHRC */


One of the Debian patches removes the comments around that preprocessor
variable.  And here in shell.c is the function where it gets used:


static void
run_startup_files ()
{
#if defined (JOB_CONTROL)
  int old_job_control;
#endif
  int sourced_login, run_by_ssh;

  /* get the rshd/sshd case out of the way first. */
  if (interactive_shell == 0 && no_rc == 0 && login_shell == 0 &&
  act_like_sh == 0 && command_execution_string)
{
#ifdef SSH_SOURCE_BASHRC
  run_by_ssh = (find_variable ("SSH_CLIENT") != (SHELL_VAR *)0) ||
   (find_variable ("SSH2_CLIENT") != (SHELL_VAR *)0);
#else
  run_by_ssh = 0;
#endif

  /* If we were run by sshd or we think we were run by rshd, execute
 ~/.bashrc if we are a top-level shell. */
  if ((run_by_ssh || isnetconn (fileno (stdin))) && shell_level < 2)
{
#ifdef SYS_BASHRC
#  if defined (__OPENNT)
  maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
#  else
  maybe_execute_file (SYS_BASHRC, 1);
#  endif
#endif
  maybe_execute_file (bashrc_file, 1);
  return;
}
}
[...]


That SYS_BASHRC thing is /etc/bash.bashrc in Debian (another one of the
Debian patches turns this on -- it's not enabled by default in upstream
bash).

Now, that "shell_level < 2" check is also intriguing.

Starting from a plain old regular urxvt running bash in my local X session
which was launched by startx:


unicorn:~$ declare -p SHLVL
declare -x SHLVL="2"
unicorn:~$ ssh localhost
greg@localhost's password: 
[...]
unicorn:~$ declare -p SHLVL
declare -x SHLVL="1"
unicorn:~$ bash -uc 'declare -p SHLVL'
declare -x SHLVL="2"
unicorn:~$ (bash -uc 'declare -p SHLVL')
/etc/bash.bashrc: line 7: PS1: unbound variable
declare -x SHLVL="1"


It looks like the subshell resets the shell_level, which is why the
behavior in run_startup_files() changes.

I still don't know how -u is involved (why the behavior of (bash -uc)
is different from that of (bash -c)).  I'll leave that analysis to
someone who actually cares about -u.

In any event, it's the confluence of FIVE factors here that matters:

 1) Using a version of bash that was compiled with SSH_SOURCE_BASHRC.
 2) Being in an ssh session, so that SSH_CLIENT is set.
 3) Using () to force a subshell which resets the shell_level.
 4) Using -u which somehow unsets PS1.
 5) Using code that checks the value of $PS1 in a startup file.

Remove any one of those factors, and the problem doesn't manifest.

probably silly Question

[gene heskett]

Greetings all;

My local home network is all behind a router running dd-wrt. sitting in 
this chair,
3 rooms away from a rock64 running armbian, I can see the rock64's 
/dev/ttyACM0, owned
by root:dialout.  I am a member of that group and logged into it from 
here. My home net

is 100% host file based.

What sort of hoops would I have to take a running swan dive thru to have 
cura, on this machine,
directly drive /sshnet/rock64/dev/ttyACM0, my Prusa MK3S+ printer? I'm 
already logged into it
over my local net twice and it would sure save me a lot of 
sneakernetting to get a design
from OpenSCAD, thru cura to slice it ad into printed PETG+CF on its 
build plate.


I mean what good is all this networking if it can't be used?

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Weird set -u error

[Greg Wooledge]

On Sat, Aug 27, 2022 at 12:11:47AM -0500, David Wright wrote:
> On Sat 27 Aug 2022 at 00:23:10 (-0400), gene heskett wrote:
> > On 8/26/22 20:35, David wrote:
> > > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge  wrote:
> > > > I get these results as well, with Debian 11's packaged bash.
> > > Yeah, sorry, I forgot to include, for the record:
> > > 
> > > $ echo $BASH_VERSION
> > > 5.1.4(1)-release
> > > $ apt list --installed bash
> > > Listing... Done
> > > bash/stable,now 5.1-2+deb11u1 amd64 [installed]
> > > 
> > > .
> > Why the miss-match, I get the same results as this myself.
> 
> bash_5.1-2+deb11u1_amd64.deb
> 
> bash is package name
> 
>  5.1 is upstream version
> 
>  2+deb11u1 is /Debian/ version
> 
>amd64 is architecture.

5.1.4 is upstream's notation for bash 5.1 with the first 4 (upstream)
patches applied.  The (1) means it was the first time bash had been
built in that directory.

If you work with upstream bash source, you may end up with something
like 5.1.4(2)-release meaning you compiled it once, changed something,
then compiled it again.  Applying upstream patches in the same directory
might give you 5.1.5(3)-release and so on.  Although typically you'll
apply more than one patch at a time, because Chet Ramey tends to release
them in groups.

Re: networking.service: start operation timed out

[Jeremy Ardley]

On 27/8/22 8:25 pm, to...@tuxteam.de wrote:

On Sat, Aug 27, 2022 at 11:55:44AM -, Curt wrote:

On 2022-08-27, Jeremy Ardley  wrote:

I'd appreciate any suggestions about how to diagnose or cure the
problem.  I have set VERBOSE=yes in /etc/default/networking


First of all ensure NetworkManager is really dead.

Your advice and the advice of Andrew M.A. Cater appear
to be antithetical.

This is only an observation and not a criticism of any kind.

There are different flavours around. I'm more the ifupdown type.
When I see Network Manager, I run away. When I see systemd...
no, I don't see systemd. Then there's the NM flavour. Then, the
systemd-networkd flavour.

Further to my longer reply on this list, there are three separate 
network configuration & management services that can be running at the 
same time on a debian system


 * networking.service
 * systemd-networkd.service
 * NetworkManager.service

The usual mode of operation under systemd has

 * networking.service always enabled
 * NetworkManager.service is usually enabled by default
 * systemd-networkd.service may or may not be enabled by default, but
   usually has no meaningful configuration

My experience is to leave networking.service handling loopback and then 
have either systemd-networkd.service to manage the more complex stuff, 
or have NetworkManager.service do this.


It's really bad news to have both NetworkManager.service and 
systemd-networkd.service trying to work at the same time.


If you have a laptop and/or wireless connections and you are a relative 
newbie, use NetworkManager.service and NetworkManager GUI to control 
stuff and will mostly do what you want - but not always, and not 
transparently. You may find rebooting the system is the only way to fix 
problems.


If you want absolute reliable control then networking.service on its own 
is a good simple choice. As an alternative, systemd-networkd-service may 
give you more features and still be reliable.


--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: networking.service: start operation timed out

[Jeremy Ardley]

On 27/8/22 7:55 pm, Curt wrote:

On 2022-08-27, Jeremy Ardley  wrote:

I'd appreciate any suggestions about how to diagnose or cure the
problem.  I have set VERBOSE=yes in /etc/default/networking


First of all ensure NetworkManager is really dead.

Your advice and the advice of Andrew M.A. Cater appear
to be antithetical.

This is only an observation and not a criticism of any kind.

Maybe it's not a useful observation, though. I don't know.




My experience with linux networking has a history of banging my head 
against poorly explained, often buggy networking configurations.


I was sort of O.K. with the /etc/network/interfaces approach and could 
manage simple networks more or less reliably.


Then NetworkManager intruded and I could see for very simple uses it 
more or less worked and was perhaps easier for newbies. NM worked in 
addition to the /etc/network/interfaces.


My problems really came about when I started trying to use 
NetworkManager and a bunch of add-on utilities to add IPv6 delegation to 
my debian router. It became obvious NM was not my friend and did a lot 
of things that were not really explicable. My networking was not 
consistent or reliable.


I took a deep breath and dived into systemd-networkd and immediately 
found many people did not trust systemd-netword and systemnd. 
Nevertheless. I read the manual many times and I could get networkd to 
do everything I wanted in a predictable manner. I did have to go through 
eradicating NetworkManager and removing some of the add-ons such as 
radvd. I was also using isc-dhcp client and it was buggy as well. It's 
now deprecated. Going to systemd-networkd removed that as one of several 
sources of problems.



So from my point of view: networkd pretty good. NetworkManager and 
friends - nah!


The only thing I did do out of the ordinary was disable systemd-resolved 
which is still problematic. I replaced it with bind as a forwarder and 
reconfigured the resolve mechanism.


To make up for my going to the dark side with networkd I set up one of 
my servers with Devuan (actually it was Armbian and I did a risky but 
successful in-place conversion). Networking on the devuan system is 
straight forward (though they still allow NetworkManager). And the lack 
of systemd makes it seem familiar and easy to use)


Getting back to the OP. I recall he was complaining about NetworkManager 
still appearing in the logs. I gave him advice to make absolutely sure 
it couldn't be started by some obscure systemd process.


I still don't really trust systemd, but I'm quite happy with the subset 
systemd-networkd.



--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: networking.service: start operation timed out

[tomas]

On Sat, Aug 27, 2022 at 11:55:44AM -, Curt wrote:
> On 2022-08-27, Jeremy Ardley  wrote:
> >>
> >> I'd appreciate any suggestions about how to diagnose or cure the
> >> problem.  I have set VERBOSE=yes in /etc/default/networking
> >>
> > First of all ensure NetworkManager is really dead.
> 
> Your advice and the advice of Andrew M.A. Cater appear
> to be antithetical.
> 
> This is only an observation and not a criticism of any kind.

There are different flavours around. I'm more the ifupdown type.
When I see Network Manager, I run away. When I see systemd...
no, I don't see systemd. Then there's the NM flavour. Then, the
systemd-networkd flavour.

There's room for all :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: networking.service: start operation timed out

[Curt]

On 2022-08-27, Jeremy Ardley  wrote:
>>
>> I'd appreciate any suggestions about how to diagnose or cure the
>> problem.  I have set VERBOSE=yes in /etc/default/networking
>>
> First of all ensure NetworkManager is really dead.

Your advice and the advice of Andrew M.A. Cater appear
to be antithetical.

This is only an observation and not a criticism of any kind.

Maybe it's not a useful observation, though. I don't know.

Re: networking.service: start operation timed out

[Brian]

On Fri 26 Aug 2022 at 22:37:08 +, Andrew M.A. Cater wrote:

> On Fri, Aug 26, 2022 at 03:06:24PM -0700, Ross Boylan wrote:
> > In Debian 11/bullseye my system keeps reporting timeouts while trying
> > to bring up the first non-loopback interface.  According to ip, the
> > interface actually is up, but ifup/down do not know that.  My 2nd
> > interface is down, and there is no mention of attempting to bring it
> > up in the logs.  I can bring up both interfaces after startup,
> > suggesting there may be something special about the initial
> > environment that is causing trouble, but I don't know what.
> > 
> > I'd appreciate any suggestions about how to diagnose or cure the
> > problem.  I have set VERBOSE=yes in /etc/default/networking
> > 
> 
> Cut /etc/network/interfaces down to the lo stanza
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> Remove EVERYTHING else.

Actuall, the lo stanza can also be removed because ifupdown will
deal with it without any help. See the changelog.Debian.

-- 
Brian.

Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]

[Computer Enthusiastic]

Hello,

> Il giorno 26 ago 2022, alle ore 19:31, piorunz  ha scritto:
> 
> On 26/08/2022 10:18, rudu wrote:
> 
>> You should be right, but after booting on both 5.10 kernels I found in
>> my repositories :
>> ii  linux-image-5.10.0-13-amd64  5.10.106-1   amd64 Linux 5.10
>> for 64-bit PCs (signed)
>> ii  linux-image-5.10.0-16-amd64  5.10.127-1   amd64 Linux 5.10
>> for 64-bit PCs (signed)
>> 
>> ... the hibernation process fails as described above ...
>> 
>> With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23)
>> x86_64 GNU/Linux hibernation works as expected.
> 
> I suggest you should report this error as soon as

A bug report is already opened [1]. A workaround (using kernel boot parameters) 
and a kernel patch are reported in [1]. Working is in progress to let the patch 
reach upstream kernel [2]. I have successfully used both the workaround 
parameters or the patch and I’m currently using a custom Debian kernel with the 
aforementioned patch to solve this bug.

HTH

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
[2] https://lists.freedesktop.org/archives/nouveau/2022-August/040756.html

Re: networking.service: start operation timed out

[Anssi Saari]

Ross Boylan  writes:

> In Debian 11/bullseye my system keeps reporting timeouts while trying
> to bring up the first non-loopback interface.

I wonder why it is that you have a script for wpa_supplicant if you
don't have wireless interfaces?

Assuming that's not the problem, I guess you'll need to iterate a lot,
enable or disable one script at a time until you find which one causes
the problem. Or mod all scripts to log when they exit too.

Re: Weird set -u error

[David]

On Sat, 27 Aug 2022 at 16:49, Tim Woodall  wrote:

> This just gets weirder and weirder.
>
> It looks like it's related to logging in with ssh:

[..]

> apt-mirror@aptmirror17:~$ ( bash -cu : )
> apt-mirror@aptmirror17:~$

> apt-mirror@aptmirror17:~$ ssh aptmirror17
> Last login: Sat Aug 27 06:23:12 2022

> apt-mirror@aptmirror17:~$ ( bash -cu : )
> /etc/bash.bashrc: line 7: PS1: unbound variable

Interesting! I can reproduce this, not sure why.

I have modified my ssh environment so that it is not the default.
But I do see a similar error message, using ssh from stable Debian 11.

[david@kablamm ~]$ ( bash -cu : )
[david@kablamm ~]$ ssh kablamm
Linux kablamm 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
Last login: Sat Aug 27 17:00:13 2022 from 10.1.1.2
[david@kablamm ~]$ ( bash -cu : )
/etc/bash.bashrc: line 7: PS1: unbound variable
[david@kablamm ~]$

So hopefully someone who understands how ssh interactive
session interacts with bash can explain this to us now :)

Re: Weird set -u error

[tomas]

On Sat, Aug 27, 2022 at 07:49:17AM +0100, Tim Woodall wrote:
> On Sat, 27 Aug 2022, to...@tuxteam.de wrote:
> 
> > On Sat, Aug 27, 2022 at 11:22:09AM +1000, David wrote:
> > > On Sat, 27 Aug 2022 at 10:27, Greg Wooledge  wrote:
> > > 
> > > > Has anyone managed to reproduce the OP's results, either getting
> > > > "interactive" from a bash -c call, or seeing *any* evidence that
> > > > /etc/bash.bashrc or ~/.bashrc is sourced from a bash -c call?
> > > 
> > > On Debian 11, when I create a test user, login on a console as that
> > > user, and duplicate the recipe provided in the original message[1],
> > > the reported problem does NOT occur:
> > 
> > Aha...
> > 
> > so main suspects are now ~/.bash_profile ~/.inputrc or some exported
> > environment lying around...
> > 
> > Cheers
> > 
> 
> This just gets weirder and weirder.
> 
> It looks like it's related to logging in with ssh:

This could be a giveaway. I tried David's test from upthread [1]
while logged in through SSH and the results are (still) the same
as his. But... my SSH is vanilla Buster, not patched, so...

[...]

> Downgrading ssh back to the version from bullseye shows it's not my
> local changes:

...but then, this makes it the more interesting :-)

Have you tried David's test?

Cheers

[1] Message-ID: 

-- 
t


signature.asc
Description: PGP signature