Chris Green wrote:
> Dan Ritter wrote:
> > Chris Green wrote:
> > > I'd like to force a different password from my own password when I do
> > > 'sudo -i' to get root privilege. However I'm a bit frightened about
> > > what might h
Dan Ritter wrote:
> Chris Green wrote:
> > I'd like to force a different password from my own password when I do
> > 'sudo -i' to get root privilege. However I'm a bit frightened about
> > what might happen if I set 'Defaults rootpw' in the su
Chris Green wrote:
> I'd like to force a different password from my own password when I do
> 'sudo -i' to get root privilege. However I'm a bit frightened about
> what might happen if I set 'Defaults rootpw' in the sudoers file but
> forget to actually c
ver I'm a bit frightened about
what might happen if I set 'Defaults rootpw' in the sudoers file but
forget to actually create a root password. (This is on systems where,
previously, I've never had a root password).
Would this totally lock me out from becoming root? Would th
I'd like to force a different password from my own password when I do
'sudo -i' to get root privilege. However I'm a bit frightened about
what might happen if I set 'Defaults rootpw' in the sudoers file but
forget to actually create a root password. (This is on sy
On Sat, May 13, 2023 at 09:07:19AM -0700, Kushal Kumaran wrote:
[...]
> The benefit is that there is no shared password. [...]
Thanks. This is one very good point indeed.
Cheers
--
t
signature.asc
Description: PGP signature
On Sat, May 13 2023 at 01:51:03 AM, Lee wrote:
> On 5/12/23, DdB wrote:
>> Am 13.05.2023 um 00:03 schrieb Lee:
>>> On 5/12/23, Stefan Monnier wrote:
> Or configure sudo to disable tty_tickets, so that the timeout (10
> minutes by default IIRC) applies to all terminals.
`sudo ba
to...@tuxteam.de wrote:
> Security is engineering: always looking for a good tradeoff.
> Not magic.
>
> (That's why I cringe when people around here scaremonger about
> "you NEED to have a password" and things. People should know
> what they are getting into, for sure, but at the same time they
>
wrote:
> On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote:
> > Le 12 mai 2023 tomas a écrit :
> >
> > >> > `sudo bash` anyone?
> > >>
> > >> also quicker done with
> > >> su -
> > >
> > > But not the same.
> >
> > Which differences do you see ?
>
> For su, you have to e
DdB (12023-05-13):
> The kind of mistakes, any user (including yourself) can initiate, grows
> considerably, if he can use any commands without even thinking.
You are right with this principle but you are mistaken in applying it.
If you want to teach users to think before typing the password, then
On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote:
> Le 12 mai 2023 tomas a écrit :
>
> >> > `sudo bash` anyone?
> >>
> >> also quicker done with
> >> su -
> >
> > But not the same.
>
> Which differences do you see ?
For su, you have to enter the root password. For sudo, there
are
Le 12 mai 2023 tomas a écrit :
>> > `sudo bash` anyone?
>>
>> also quicker done with
>> su -
>
> But not the same.
Which differences do you see ?
On 5/12/23, DdB wrote:
> Am 13.05.2023 um 00:03 schrieb Lee:
>> On 5/12/23, Stefan Monnier wrote:
Or configure sudo to disable tty_tickets, so that the timeout (10
minutes by default IIRC) applies to all terminals.
>>>
>>> `sudo bash` anyone?
>>
>> me! me! but I also have
> (...)
>> %
Am 13.05.2023 um 00:03 schrieb Lee:
> On 5/12/23, Stefan Monnier wrote:
>>> Or configure sudo to disable tty_tickets, so that the timeout (10
>>> minutes by default IIRC) applies to all terminals.
>>
>> `sudo bash` anyone?
>
> me! me! but I also have
(...)
> %adm ALL = (root) NOPASSWD:
On 5/12/23, Stefan Monnier wrote:
>> Or configure sudo to disable tty_tickets, so that the timeout (10
>> minutes by default IIRC) applies to all terminals.
>
> `sudo bash` anyone?
me! me! but I also have
# cat /etc/sudoers.d/adm-grp-privs
# members of adm can run certain commands as root w
On 2023-05-12, Tom Reed wrote:
>> Tom Reed (12023-05-12):
>>> otherwise every time i have to input password for sudo.
>>
>> Yes, that is the point.
>>
>> If “every time” is a lot for you, maybe your use habits need to be
>> reviewed.
>>
>
> that's normal. for example, I have to check every kind of
On Fri, May 12, 2023 at 05:46:21PM +0200, Michel Verdier wrote:
> Le 12 mai 2023 Stefan Monnier a écrit :
>
> >> Or configure sudo to disable tty_tickets, so that the timeout (10
> >> minutes by default IIRC) applies to all terminals.
> >
> > `sudo bash` anyone?
>
> also quicker done with
> su -
Le 12 mai 2023 Stefan Monnier a écrit :
>> Or configure sudo to disable tty_tickets, so that the timeout (10
>> minutes by default IIRC) applies to all terminals.
>
> `sudo bash` anyone?
also quicker done with
su -
On 12/05/2023 21:00, Byung-Hee HWANG (황병희) wrote:
On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote:
`sudo bash` anyone?
AMAZING! Thanks for tip, Stefan ^^^
Isn't it a way to get e.g. ~/.bash_history owned by root?
sudo -i
should be better
Hi Stefan,
On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote:
> > Or configure sudo to disable tty_tickets, so that the timeout (10
> > minutes by default IIRC) applies to all terminals.
>
> `sudo bash` anyone?
>
AMAZING! Thanks for tip, Stefan ^^^
Sincerely, Byung-Hee
--
^고맙습니다 _布德天下
Le 12 mai 2023 Tom Reed a écrit :
> that's normal. for example, I have to check every kind of logs (mail,
> webserver, systems etc). They require sudo then.
Logs are with adm gid, so just add your user to the group adm to be able
to consult logs.
Stefan Monnier (12023-05-12):
> `sudo bash` anyone?
Why not “sudo start-gnome” or logging as root on the display manager
while you are at it?
Regards,
--
Nicolas George
> Or configure sudo to disable tty_tickets, so that the timeout (10
> minutes by default IIRC) applies to all terminals.
`sudo bash` anyone?
Stefan
Greg Wooledge (12023-05-12):
> If you're launching a terminal, running a single sudo command, closing
> the terminal, opening a new terminal, etc. ... then perhaps you should
> stop doing that. Leave your terminal open, at least until you're done
> with whatever administrative task you're doing.
On Fri, May 12, 2023 at 08:13:31PM +0800, Tom Reed wrote:
> that's normal. for example, I have to check every kind of logs (mail,
> webserver, systems etc). They require sudo then.
If you check the logs all at once, as part of a daily routine, then you
only have to type the password one time, at t
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote:
> Hello
>
> what's the right way to add an user to run sudo without password?
> I have to edit /etc/sudoers by manual. But I don't think it's a grace way.
>
> Thanks.
> Tom
>
As others have said: su
Tom Reed (12023-05-12):
> that's normal. for example, I have to check every kind of logs (mail,
> webserver, systems etc). They require sudo then.
No they do not. You just have to adjust files permissions if they are
not correct by default, which they usually are.
My crystal ball tells me you neg
On Fri, May 12, 2023 at 08:03:00PM +0800, Tom Reed wrote:
> for a common account, such as tom, a nopasswd sudo also makes sense?
> otherwise every time i have to input password for sudo.
Within a given terminal session, you only have to enter your passwors
once. This will allow passwordless sudo
> Tom Reed (12023-05-12):
>> otherwise every time i have to input password for sudo.
>
> Yes, that is the point.
>
> If “every time” is a lot for you, maybe your use habits need to be
> reviewed.
>
that's normal. for example, I have to check every kind of logs (mail,
webserver, systems etc). They
Tom Reed (12023-05-12):
> otherwise every time i have to input password for sudo.
Yes, that is the point.
If “every time” is a lot for you, maybe your use habits need to be
reviewed.
Regards,
--
Nicolas George
> On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote:
>> what's the right way to add an user to run sudo without password?
>> I have to edit /etc/sudoers by manual. But I don't think it's a grace
>> way.
>
> *Without password*?? Yes, that w
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote:
> what's the right way to add an user to run sudo without password?
> I have to edit /etc/sudoers by manual. But I don't think it's a grace way.
*Without password*?? Yes, that will require a manual edit.
There is
Hello
what's the right way to add an user to run sudo without password?
I have to edit /etc/sudoers by manual. But I don't think it's a grace way.
Thanks.
Tom
On Mon, 2023-05-08 at 17:08 -0600, Charles Curley wrote:
> On Mon, 8 May 2023 17:27:24 +0200
> wrote:
>
> > (2) add your user to the sudo group. I'd prefer (2).
>
> usermod -a -G sudo
Oh Good! Thanks for tip!
Sincerely, Byung-Hee
--
^고맙습니다 _布德天下_ 감사합니다_^))//
On Mon, 8 May 2023 19:41:35 -0400
Greg Wooledge wrote:
> Wanna be lazier?
Nah. I'm too lazy to edit my script. :-)
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
On Mon, May 08, 2023 at 05:08:44PM -0600, Charles Curley wrote:
> On Mon, 8 May 2023 17:27:24 +0200
> wrote:
>
> > (2) add your user to the sudo group. I'd prefer (2).
>
> usermod -a -G sudo
>
> I'm lazy. I have that in a script.
Wanna be lazier? In Debian, you can do it this way:
addu
On Mon, 8 May 2023 17:27:24 +0200
wrote:
> (2) add your user to the sudo group. I'd prefer (2).
usermod -a -G sudo
I'm lazy. I have that in a script.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
ng that
> skips over adding the first user (created during install) to sudoers
> (i.e. "the operator created root, the operator will 'su root' when they
> want to be root").
>
> As I recall, the installer asks if you want to create root, or use sudo.
Nitpic
On Mon, May 08, 2023 at 11:20:17AM -0400, Dan Ritter wrote:
> Igor Korot wrote:
> > Hi, ALL,
> > Is there a reason for the default install
> > I immediately get the error in the subj?
> >
> > Basically trying to run:
> >
> > [code]
> > sudo apt-get install
> > [/code]
>
>
> Depending on the c
Igor Korot wrote:
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
>
> Basically trying to run:
>
> [code]
> sudo apt-get install
> [/code]
Depending on the choices you made during installation, either:
- root has a password and sudo is not in
On May 08, 2023, Igor Korot wrote:
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
You likely created a root account during the initial setup. Doing that
skips over adding the first user (created during install) to sudoers
(i.e. &quo
On Mon, 8 May 2023 10:16:33 -0500
Igor Korot wrote:
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
>
> Basically trying to run:
>
> [code]
> sudo apt-get install
> [/code]
>
> Thank you.
>
Sudi itself requires configuration as it does not b
o
It seems you gave root a password. Now you have to become root once,
the "traditional" way and either (1) edit the sudoers file to add
your user, or (2) add your user to the sudo group. I'd prefer (2).
Cheers
--
t
signature.asc
Description: PGP signature
Hi, ALL,
Is there a reason for the default install
I immediately get the error in the subj?
Basically trying to run:
[code]
sudo apt-get install
[/code]
Thank you.
On 17/10/21 20:41, Gregor Zattler wrote:
PS: in my opinion you should avoid creating a sudoers file unless you
really know what you are doing. the defaults are very insecure.
So force sudo to use the root passwd.
After you ensure your root passwd works, simply add the line:
Defaults
Hi Peter,
* Peter Ehlert [2021-10-14; 06:30]:
> PS: in my opinion you should avoid creating a sudoers file unless you
> really know what you are doing. the defaults are very insecure.
Could you please elaborate on this, or provide a pointer?
Thanks; Gregor
--
-... --- .-. . -.. ..--.. ...-.-
On Wed, Aug 11, 2021 at 08:16:04AM -0400, Bob Bernstein wrote:
> The package visudo not being installed on this system, [...]
visudo is not a separate package. It's a program included in the
sudo package.
unicorn:~$ type visudo
visudo is /usr/sbin/visudo
unicorn:~$ dpkg -S /usr/sbin/visudo
sudo:
w?
THANKS ALL for the spirited response to my sudo brief
psychotic episode.
The package visudo not being installed on this system, su, then
a permission change, permitted me to remove that darned space
between '%' and 'sudo' on that line in /etc/sudoers with good
old jed
Roger Price [2021-08-10 11:11:24] wrote:
> On Tue, 10 Aug 2021, Bob Bernstein wrote:
>> Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this
>> file using 'sudo nsno /etc/sudoers'.
> My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/su
On Tue, 10 Aug 2021, Stefan Monnier wrote:
Roger Price [2021-08-10 11:11:24] wrote:
On Tue, 10 Aug 2021, Bob Bernstein wrote:
Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this
file using 'sudo nsno /etc/sudoers'.
My impulse would be to use VISUAL=/usr/bin/em
On 2021-08-10 07:19, Bob Bernstein wrote:
My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like this:
23 # Allow members of group sudo to execute any comm$
24 % sudo ALL=(ALL:ALL) ALL
Is that '%' a comment char? The line numbers shown were provided by
nano. I know, I kn
On 8/10/2021 1:11 PM, Greg Wooledge wrote:
On Tue, Aug 10, 2021 at 09:13:22AM +0200, john doe wrote:
Fulling around is the best way to learn if you can take the time to fix
the issue(s) that your impulsivity has caused!!! :)
(Fooling around.) If you do choose to fool around with sudoers
If you do choose to fool around with sudoers, please
> keep a root shell open at all times. Don't cut yourself off from root
> by counting on being able to do "sudo nano /etc/sudoers" again, because
> you might have broken sudo.
...or learn how to access your "dead&
Greg Wooledge (12021-08-10):
> (Fooling around.) If you do choose to fool around with sudoers, please
> keep a root shell open at all times. Don't cut yourself off from root
> by counting on being able to do "sudo nano /etc/sudoers" again, because
> you might have bro
On Tue, Aug 10, 2021 at 09:13:22AM +0200, john doe wrote:
> Fulling around is the best way to learn if you can take the time to fix
> the issue(s) that your impulsivity has caused!!! :)
(Fooling around.) If you do choose to fool around with sudoers, please
keep a root shell open at all
On Tue, Aug 10, 2021 at 11:11:24AM +0200, Roger Price wrote:
My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers
(for the OP:) the tool "visudo" is a wrapper around an editor (despite
its name, the editor does not have to be vi, as Roger demonstrates here)
tha
On Tue, 10 Aug 2021, Bob Bernstein wrote:
Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this file
using 'sudo nsno /etc/sudoers'.
My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers
Roger
Bob Bernstein writes:
> Full disclosure: In a typical Bob fit of impulsivity I, yes, edited
> this file using 'sudo nsno /etc/sudoers'.
In general, consider making a backup of config files before editing.
Here's a sudo mini course:
- Consider what needs to run as r
On Tue, 10 Aug 2021 08:57:46 +0200
wrote:
> What I'm not sure is whether the whitespace between the '%' and
> the 'sudo' is relevant. My /etc/sudoers hasn't that.
Mine is the same - no space = %sudo ALL=(ALL:ALL) ALL
Best
Keith Bainbridge
keithrbaugro...@gmail.com
On 8/10/2021 8:19 AM, Bob Bernstein wrote:
My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like this:
I would suggest to use the directory '/etc/sudoers.d' instead of
modifying the 'sudoers' file.
23 # Allow members of group sudo to execute any comm$
24 % sud
On Tue, 10 Aug 2021 at 16:58, wrote:
> On Tue, Aug 10, 2021 at 02:19:18AM -0400, Bob Bernstein wrote:
> > My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like
> > this:
> > 23 # Allow members of group sudo to execute any comm$
> > 24 % sudo ALL=(ALL:ALL
On Tue, Aug 10, 2021 at 02:19:18AM -0400, Bob Bernstein wrote:
> My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like
> this:
>
> 23 # Allow members of group sudo to execute any comm$
> 24 % sudo ALL=(ALL:ALL) ALL
>
> Is that '%' a comment char?
My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like
this:
23 # Allow members of group sudo to execute any comm$
24 % sudo ALL=(ALL:ALL) ALL
Is that '%' a comment char? The line numbers shown were provided
by nano. I know, I know, please keep reading.
Full disclo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-11-16 19:02, Andreas Henriksson wrote:
> For what it's worth, if you want to avoid logging out/in you can
> temporarily join the group in your shell by using "newgrp sudo".
Thank you for that tip; it is useful to know.
Ken
-BEGIN PGP
Ken Heard [2015-11-16 13:50:09+07] wrote:
> On 2015-11-15 23:26, Teemu Likonen wrote:
>> Maybe you added the user to the "undo" group
>
> Surely you mean the "sudo" group?
Yes, of course. :-)
signature.asc
Description: PGP signature
Hello!
On Mon, Nov 16, 2015 at 01:50:09PM +0700, Ken Heard wrote:
[...]
> My eureka moment! I forgot to logout and in again as my user before
> testing the various options.
[...]
For what it's worth, if you want to avoid logging out/in you can
temporarily join the group in your shell by using "ne
ser privilege
specification" section in the sudoers file the following line DOES work:
ken ALL=NOPASSWD: ALL
However, removing that line, and in the TDE User Manager (Kuser)
simply adding my user to the "sudo" group does NOT work. That option
DOES nevertheless work in my Jessie box
Did you check the permissions?
-r--r- 1 root root 1011 Oct 4 21:58 /etc/sudoers
On Sun, Nov 15, 2015 at 5:27 PM, Ric Moore wrote:
> On 11/15/2015 11:18 AM, Joe wrote:
>
>> On Sun, 15 Nov 2015 10:44:10 -0500
>> Ric Moore wrote:
>>
>> On 11/14/2015 03:01 P
On 11/15/2015 11:18 AM, Joe wrote:
On Sun, 15 Nov 2015 10:44:10 -0500
Ric Moore wrote:
On 11/14/2015 03:01 PM, Joe wrote:
Your example will
still ask for a password, and anyway it's either/or: you can either
add yourself to the sudo group or add your name to sudoers, you
don't need
Ric Moore [2015-11-15 10:44:10-05] wrote:
> On 11/14/2015 03:01 PM, Joe wrote:
>> it's either/or: you can either add yourself to the sudo group or add
>> your name to sudoers, you don't need both.
>
> I had to, before it would work. YMMV, Ric
Maybe you added t
On Sun, 15 Nov 2015 10:44:10 -0500
Ric Moore wrote:
> On 11/14/2015 03:01 PM, Joe wrote:
> Your example will
> > still ask for a password, and anyway it's either/or: you can either
> > add yourself to the sudo group or add your name to sudoers, you
> > don't nee
On 11/14/2015 03:01 PM, Joe wrote:
Your example will
still ask for a password, and anyway it's either/or: you can either add
yourself to the sudo group or add your name to sudoers, you don't need
both.
I had to, before it would work. YMMV, Ric
--
My father, Victor Moore (Vic) u
Ken Heard [2015-11-14 15:11:05+07] wrote:
> In my Wheezy box I want to be able to run any root command as my user
> without having to enter a password to do so.
> # ken ALL=NOPASSWD: ALL
How about this:
ken ALL = (root) NOPASSWD: ALL
Works here but this is Debian 8 (Jessie), not Wheezy.
want to be able to run any root command as my
> >> user without having to enter a password to do so. I assume that
> >> there are two ways to do so: either make my user a member of the
> >> sudo group, or add a line to sudoers giving such privileges to my
> >> user. Ne
to do so: either make my user a member of the sudo group, or
add a line to sudoers giving such privileges to my user. Neither worked.
You have to add the "NOPASSWD" option. Check the "sudoers" man page.
Add your user to the sudo group like this in /etc/group :
sudo:x:27:r
group, or
add a line to sudoers giving such privileges to my user. Neither worked.
You have to add the "NOPASSWD" option. Check the "sudoers" man page.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In my Wheezy box I want to be able to run any root command as my user
without having to enter a password to do so. I assume that there are
two ways to do so: either make my user a member of the sudo group, or
add a line to sudoers giving such
On Sun, May 3, 2015, at 11:56, Avinash Sonawane wrote:
> On Sun, May 3, 2015 at 8:24 PM, Avinash Sonawane
> wrote:
> > On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote:
> >> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> >>> So will it work if I add `authrequired
On Sun, May 03, 2015 at 03:20:05PM +0200, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit :
> > There's nothing wrong with the file permissions. By default, root's
> > shell reads /etc/environment, but users do not. To be honest I'm not
> > sure why that is the
> sudo, sanitizing the environment is just a matter of convenience.
We don't know whether the user shares the box, has other users who are
limited, who would also be affected by the introduction of env_var in sudoers,
nor about anyone else reading, copying or adapting the answer for their
On Sun, May 3, 2015 at 8:24 PM, Avinash Sonawane wrote:
> On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote:
>> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
>>> So will it work if I add `authrequiredpam_env.so`
>>> to lightdm, lightdm-greeter and lightdm-a
On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
>> So will it work if I add `authrequiredpam_env.so`
>> to lightdm, lightdm-greeter and lightdm-autologin files?
>
> Try.
Awesome! It worked! I added `auth
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> So will it work if I add `authrequiredpam_env.so`
> to lightdm, lightdm-greeter and lightdm-autologin files?
Try.
> So I should file this against jessie, lightdm or xfce(as in GNOME
> /etc/environment was getting
On Sun, May 3, 2015 at 7:15 PM, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
>> I think I am using lightdm as display manager/login manager. (Any way
>> to find out which is?)
>
> You can probably see what display manager is running with "ps".
Yes. It is
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> I think I am using lightdm as display manager/login manager. (Any way
> to find out which is?)
You can probably see what display manager is running with "ps".
> And in lightdm, lightdm-autologin and lightdm-greeter I see:
>
> # Loa
On Sun, May 3, 2015 at 6:51 PM, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
>> I am using Jessie with XFCE.
>
> Look in /etc/pam.d/ if there is a file related to xfce and its display
> manager.
$ ls /etc/pam.d
-rw-r--r-- 1 root root 235 Sep 30 2014
Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit :
> This is inevitable with http_proxy, sadly, as there is no one place you can
> put things that will guarantee that all processes with get them as environment
> variables, and no guarantee that all processes will honour http_proxy anywa
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> I am using Jessie with XFCE.
Look in /etc/pam.d/ if there is a file related to xfce and its display
manager. If there is, check that pam_env.so is invoked. If it is not, add it
by imitating another file that does it right (xdm for ex
by each
specific PAM configuration; IMHO, it should be in common-session.
> To solve your specific apt-related problem, you can also add 'Defaults
> env_file += /etc/environment' to sudoers and it will be sourced by sudo
> when you use it to invoke another command.
This is bugware
I am using Jessie with XFCE.
When I try to invoke any network using utility as normal user my
/etc/environment is not getting used as if for normal user
/etc/environment doesn't exist. While when I try to invoke the same
utility as a root user the proxy set in /etc/environment just works as
if /et
On Sun, May 03, 2015 at 05:09:20PM +0530, Avinash Sonawane wrote:
> may be it's file permissions. For me
> $ ls -la /etc/environment /etc/sudoers
> -rw-r--r-- 1 root root 117 May 2 17:41 /etc/environment
> -r--r- 1 root root 778 May 3 16:13 /etc/sudoers
There's nothi
ost guaranteed to define a bash function or alias or something
else to save on typing. By which point they may as well have put it in the
apt configuration.
> I do not know if the order if the directives in /etc/sudoers matters, as was
> suggested earlier, but that would be the first thing
/environment is available to
>> root only.
>
> So there you are: the problem is not with sudo, it is with the environment
> of your normal user.
>
> Did you close your login session and start a fresh one since you changed
> /etc/environment?
I rebooted multiple times since
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> No. Sorry for not being so clear. When I say `$ env` (i.e. as normal
Do not worry, everyone forgets to check basic things from time to time.
> user) it doesn't show http_proxy. As if /etc/environment is not
> available to normal use
Here is something. When I say `$ wget http://foobar` (normal user)
then it says unable to resolve (proxy doesn't work) but when I say `#
wget http://foobar` (root user) the resource gets downloaded (proxy
works)
So I think the real problem is /etc/environment is not getting used
for normal user wh
On Sun, May 3, 2015 at 4:27 PM, Nicolas George wrote:
> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
>> When I say `# env` I can see http_proxy=http://192.168.6.254:3128 but
>> when I say `$ sudo env` there's no http_proxy variable printed.
>>
>> What's going on?
>
> I assume tha
Avinash Sonawane writes:
> > %sudo ALL=NOPASSWD: ALL
>
> What does this line do? NOPASSWD?
it means that if someone is in sudo group, sudo command does not ask
password.
-- juha
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac
On Sun, 3 May 2015 16:24:15 +0530
Avinash Sonawane wrote:
> On Sun, May 3, 2015 at 3:58 PM, Juha Heinanen wrote:
>
> > %sudo ALL=NOPASSWD: ALL
>
> What does this line do? NOPASSWD?
It lets you run commands as another user (normally root) without
entering your password.
Petter
--
"I'm ioniz
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit :
> When I say `# env` I can see http_proxy=http://192.168.6.254:3128 but
> when I say `$ sudo env` there's no http_proxy variable printed.
>
> What's going on?
I assume that you checked that "env" without "sudo" shows http_proxy?
If s
On Sun, May 3, 2015 at 3:58 PM, Juha Heinanen wrote:
> %sudo ALL=NOPASSWD: ALL
What does this line do? NOPASSWD?
--
Avinash Sonawane (RootKea)
PICT, Pune
http://www.rootkea.wordpress.com
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
1 - 100 of 185 matches
Mail list logo
