Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211351 > unrolled thread

Buster install

Back to article view | Back to linux.debian.user

Contents

  Buster install Curt Howland <Howland@priss.com> - 2019-07-13 22:40 +0200
    Re: Buster install Ansgar Burchardt <ansgar@43-1.org> - 2019-07-13 23:10 +0200
    Re: Buster install Curt Howland <Howland@priss.com> - 2019-07-13 23:30 +0200
      Re: Buster install <tomas@tuxteam.de> - 2019-07-14 00:10 +0200
        Re: Buster install Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-14 08:20 +0200
          Re: Buster install <tomas@tuxteam.de> - 2019-07-14 11:50 +0200
            Re: Buster install Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-15 16:00 +0200
    Re: Buster install Curt Howland <Howland@priss.com> - 2019-07-14 00:20 +0200
      Re: Buster install Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-14 08:40 +0200
        Re: Buster install Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-07-14 21:30 +0200
        Re: Buster install Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-15 16:30 +0200
          Re: Buster install Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-16 09:10 +0200
            Re: Buster install Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-16 15:20 +0200

#211351 — Buster install

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Just installed Buster.

I know some kinks will work out, but seriously, /sbin is not in root's 
path by default?



- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCXSpACgAKCRC2T1fo1pHh
qTa0AP4tgLFOr49z7uNMXogmC9Syb1gH0A35CJA3/QI4egOesAD/Xyvo6vdQF9qZ
Hko2u3p7LBoEv1BBhMiS46F30QeAIs8=
=D5D2
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#211352

Curt Howland writes:
> I know some kinks will work out, but seriously, /sbin is not in root's 
> path by default?

/sbin is in root's path by default.  However Debian now uses a different
implementation of `su` which no longer changes PATH by default:

+---
|   - new 'su' (with no args, i.e. when preserving the environment) also
|     preserves PATH and IFS, while old su would always reset PATH and IFS
|     even in 'preserve environment' mode.
|   [...]
|   The first difference is probably the most user visible one. Doing
|   plain 'su' is a really bad idea for many reasons, so using 'su -' is
|   strongly recommended to always get a newly set up environment similar
|   to a normal login.
+---[ /usr/share/doc/util-linux/NEWS.Debian.gz ]

Ansgar

[toc] | [prev] | [next] | [standalone]

#211353

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Saturday 13 July 2019, Curt Howland was heard to say:
> Just installed Buster.
>
> I know some kinks will work out, but seriously, /sbin is not in
> root's path by default?

Ok, the problem is /etc/profile is not being run when the "su" command 
is used. If I log in as root, the path is set just fine.




- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCXSpLygAKCRC2T1fo1pHh
qdrZAP0VEtLlfxJh0xoE/pfV/mV0KEw9PdyZwhWxZ+swyYp8AQD8DiPzTm7wiuIA
BJQi3SMy3AdCUrhwrYkpsR2BPQtN65A=
=cnNJ
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#211354

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 13, 2019 at 05:23:22PM -0400, Curt Howland wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Saturday 13 July 2019, Curt Howland was heard to say:
> > Just installed Buster.
> >
> > I know some kinks will work out, but seriously, /sbin is not in
> > root's path by default?
> 
> Ok, the problem is /etc/profile is not being run when the "su" command 
> is used. If I log in as root, the path is set just fine.

Use "su -" (or "sudo -s") if you want to achieve that...

Yes, this change has tripped up some folks...

Cheers
-- t 

[toc] | [prev] | [next] | [standalone]

#211367

[Multipart message — attachments visible in raw view] — view raw

On Du, 14 iul 19, 00:09:09, tomas@tuxteam.de wrote:
> On Sat, Jul 13, 2019 at 05:23:22PM -0400, Curt Howland wrote:
> > 
> > Ok, the problem is /etc/profile is not being run when the "su" command 
> > is used. If I log in as root, the path is set just fine.
> 
> Use "su -" (or "sudo -s") if you want to achieve that...

You probably meant 'sudo -i' ;)

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

[toc] | [prev] | [next] | [standalone]

#211374

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jul 14, 2019 at 09:11:17AM +0300, Andrei POPESCU wrote:
> On Du, 14 iul 19, 00:09:09, tomas@tuxteam.de wrote:

[...]

> > Use "su -" (or "sudo -s") if you want to achieve that...
> 
> You probably meant 'sudo -i' ;)

Yep, better.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#211406

On Sun, Jul 14, 2019 at 11:42:52AM +0200, tomas@tuxteam.de wrote:
> On Sun, Jul 14, 2019 at 09:11:17AM +0300, Andrei POPESCU wrote:
> > On Du, 14 iul 19, 00:09:09, tomas@tuxteam.de wrote:
> > > Use "su -" (or "sudo -s") if you want to achieve that...
> > 
> > You probably meant 'sudo -i' ;)
> 
> Yep, better.

The closest replacement for stretch's "su" (change PATH but do not change
working directory) is "sudo -s".  If you want to replace the "su" in
this workflow:

make
make check
su
make install

... you want "sudo -s".

"su -" or "sudo -i" changes your working directory as well as your PATH.
In some cases, that may be desirable, but in others it's not.

[toc] | [prev] | [next] | [standalone]

#211357

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Saturday 13 July 2019, Ansgar Burchardt was heard to say:

|   The first difference is probably the most user visible one. Doing
|   plain 'su' is a really bad idea for many reasons, so using 'su -' 
is
|   strongly recommended to always get a newly set up environment 
similar
|   to a normal login.

Well, that's a remarkably stupid thing to change.

Thank you, I will alias it because that's impossibly stupid.


- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCXSpX/QAKCRC2T1fo1pHh
qUkzAP49jbOL7aRWt2ll3ikWGaLnUb56khAmlhSBRnpw0qz6BwD+K/Su62QcU768
EHkqKvTwYIQokhf4JOrNXh1VZbpDRrc=
=wrMi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#211368

[Multipart message — attachments visible in raw view] — view raw

On Sb, 13 iul 19, 18:15:25, Curt Howland wrote:
> On Saturday 13 July 2019, Ansgar Burchardt was heard to say:
> 
> |   The first difference is probably the most user visible one. Doing
> |   plain 'su' is a really bad idea for many reasons, so using 'su -' 
> is
> |   strongly recommended to always get a newly set up environment 
> similar
> |   to a normal login.
> 
> Well, that's a remarkably stupid thing to change.

In your opinion.

As I see it the new su (behaviour) clearly distinguishes between 
"preserve environment" and "don't preserve environment".

What's the point of preserving the environment, but resetting PATH?

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

[toc] | [prev] | [next] | [standalone]

#211390

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jul 14, 2019, 1:30 AM Andrei POPESCU <andreimpopescu@gmail.com>
wrote:

>
> As I see it the new su (behaviour) clearly distinguishes between
> "preserve environment" and "don't preserve environment".
>
> What's the point of preserving the environment, but resetting PATH?
>

It comes in handy debugging scripts. Some might also consider it an easy
safety mechanism. But it could naturally be the opposite, depending on how
clean the installation is thought to be.

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

[toc] | [prev] | [next] | [standalone]

#211409

On Sun, Jul 14, 2019 at 09:29:55AM +0300, Andrei POPESCU wrote:
> What's the point of preserving the environment, but resetting PATH?

It assumes you trust yourself, and that you did not intentionally
sabotage your own environment.

The changes that you, the owner and administrator of your computer, have
made to your environment for your own convenience and efficiency, should
be preserved when you "su".  Examples of that include user interface
customizations to the pager that you use for reading man pages, which is
something that *I* do pretty often when I'm su-ed to root.  Maybe you've
memorized all of the options for a program you only use once a year.
I haven't.

Changing PATH is also for efficiency and convenience.  There's a
bunch of stuff that you only use when you're root, and most of
it's in /sbin and /usr/sbin.  So you only want those directories
added to your PATH when you're root.  You *could* run around with
PATH=/usr/local/sbin:/usr/local/bin:.... all day long, but that's slightly
less efficient when your shell has to look up a new command's location.

The implementation of su in stretch-and-earlier is the best of all worlds.
You get PATH set correctly before and after, you get to keep all of your
customized environment settings like $PAGER and $LESS, and it doesn't
change your working directory in the middle of your workflow.

What are the replacement choices?

 * "su -" throws away your custom environment AND changes your working
   directory.

 * "sudo -i" throws away your custom environment AND changes your working
   directory.

 * "sudo -s" throws away most of your custom environment (unless configured
   in a non-default way).

 * Putting /usr/local/sbin (et al.) in your regular PATH and using "su"
   lets you keep your custom environment and your working directory, at
   the cost of inefficiency when you're not root.  This may be extremely
   difficult with some Display Managers.

 * Putting ALWAYS_SET_PATH yes in /etc/login.defs lets you keep your
   customized enviornment and your working directory, without imposing
   an extra cost when you're not root.

Objectively, the last one is the best choice, but I have *just* enough
inertia that I don't really want to do that... so I've settled for sudo -s.
For now, anyway.  I reserve the right to change my mind and do something
else if I get sufficiently annoyed.

On a purely selfish and practical note, the *main* thing that I care about
in my customized environment, when I'm root, is one environment variable:
LESS=-X.  I utterly *hate* it when I read a man page, find the section I
need, get it positioned exactly right on the screen, "q" to quit, and
then... the manual vanishes from the screen.  That's utterly spiteful.
I need that man page to STAY VISIBLE so I can apply the information in it
while I'm typing my next command.

It seems that inside a screen session, "man foo" acts as if I had LESS=-X
in my environment, even when I don't.  So, one more reason that "sudo -s"
is acceptable to me, right now, is that I can live without that piece of
my customized environment, as long as I'm inside screen.

[toc] | [prev] | [next] | [standalone]

#211421

[Multipart message — attachments visible in raw view] — view raw

On Lu, 15 iul 19, 10:20:34, Greg Wooledge wrote:
> 
> The implementation of su in stretch-and-earlier is the best of all worlds.
> You get PATH set correctly before and after, you get to keep all of your
> customized environment settings like $PAGER and $LESS, and it doesn't
> change your working directory in the middle of your workflow.

It's probably not affecting me because of a different workflow.
 
> What are the replacement choices?
> 
>  * "su -" throws away your custom environment AND changes your working
>    directory.
> 
>  * "sudo -i" throws away your custom environment AND changes your working
>    directory.
> 
>  * "sudo -s" throws away most of your custom environment (unless configured
>    in a non-default way).
> 
>  * Putting /usr/local/sbin (et al.) in your regular PATH and using "su"
>    lets you keep your custom environment and your working directory, at
>    the cost of inefficiency when you're not root.  This may be extremely
>    difficult with some Display Managers.
> 
>  * Putting ALWAYS_SET_PATH yes in /etc/login.defs lets you keep your
>    customized enviornment and your working directory, without imposing
>    an extra cost when you're not root.
> 
> Objectively, the last one is the best choice, but I have *just* enough
> inertia that I don't really want to do that... so I've settled for sudo -s.
> For now, anyway.  I reserve the right to change my mind and do something
> else if I get sufficiently annoyed.

Let me suggest an alternative workflow:

  * Do everything from a user account, except for the (very few) actions 
    that actually require elevated privileges.


Looking up man pages, retrieving package information, check networking 
info[1], etc. is only ever done from the user account. I switch to root 
only when I need to do apt update/upgrade/install/etc., edit 
configuration files, restart daemons/system, etc.

This has the nice (for me) side effect that the root environment 
requires very little (if any) customization[2] as all customizations I 
really care about are done for my user account.

In practice I'm doing this with screen configured to always start a user 
shell and a root shell (using sudo -i). This also provides me with a 
consistent environment, regardless if I'm logged in locally or via ssh.


[1] iproute2 (i.e. ip and friends) have been a major improvement for my 
workflow in this regard, in addition to being shorter to type ;)

[2] currently the only customization I need for root is
'update-alternatives --config editor', which is useful for the user 
account as well ;) It also helps that vim in its default configuration 
has enough advanced features for my use.

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

[toc] | [prev] | [next] | [standalone]

#211425

On Tue, Jul 16, 2019 at 10:08:55AM +0300, Andrei POPESCU wrote:
> Let me suggest an alternative workflow:
> 
>   * Do everything from a user account, except for the (very few) actions 
>     that actually require elevated privileges.

Yes, of course, obviously.  This is exactly what I do, and what I assume
everyone else does.

I'm talking about that one time a month (or year) where you need a root
shell for some special purpose.  apt-get update/upgrade don't count,
because those can be done simply by sticking sudo in front of them.  Also,
they're ridiculously common, so it's not like I need to read the man pages
for them any more.

> Looking up man pages, retrieving package information, check networking 
> info[1], etc. is only ever done from the user account. I switch to root 
> only when I need to do apt update/upgrade/install/etc., edit 
> configuration files, restart daemons/system, etc.

For most of those, I don't even NEED a root shell.  I can stick sudo
in front of a regular command as needed.

I'm talking about the exceptions to the rule.  Those times when you need
to be root *for a while*, either because you're working on files that
are inside a directory without universal r/x permissions, or because
you're doing a bunch of commands in a row, etc.  Or simply because the
remote server doesn't have sudo installed.

These things are just rare enough that it's not worth it (to me) to
spend a whole bunch of time reconfiguring every system to have the
desired behavior from "su".  But other people are free to run their
cost evaluations and come up with different results.

The reason I specifically pointed out man pages is because for me, the
typical sequence of events is something like:

ssh into remote server as root
start fixing stuff
realize that I don't know everything I need to know
realize that the man pages on my local workstation will not match the server
man foobar on the server
headdesk because the man page just vanished when I pressed q

Now, the "obvious" fix to that issue is to ssh in as myself, and then
use "su" to become root.  But that gives the wrong PATH under buster.
Or, I could ssh in as myself, then "sudo -s" to get a shell (if sudo is
even installed), but then I lose my customized environment.

I've recently learned that "sudo -sE" may be a better choice, as that
might preserve your environment.  Or it might not.  It's really hard
to tell, because sudoers(5) is one of the worst man pages in history,
written by and for aliens.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web